Pourquoi une architecture Web devrait-elle être couplée de manière lâche?

Question

Quand je regarde ASP.NET les projets MVC chaque fois que je vois lâche couplé à l'architecture.

Pour ce faire j'ai besoin d'un couplage lâche dans une architecture web (si je ne fais pas de tests unitaires)?

Quels sont les avantages et les inconvénients de cette situation?

Quelle est la principale raison de dissocier les couches/classes?

Que faire si je ne veux pas changer mon DAL par exemple? Je veux dire, quand est-ce que je change toute ma DAL?! J'ai donc pu couple mon DAL à l'INTERFACE utilisateur. Ce qui est mal à cela?

Answer 1

Le couplage lâche vous permet d'apporter des modifications dans un domaine de l'application sans affecter les autres. Théoriquement, cela vous permet de faire des choses comme changer votre couche d'accès aux données sans reconstruire vos couches d'entreprise ou d'interface utilisateur.

Cela rend définitivement vos applications plus flexibles, plus aptes au changement et plus faciles à maintenir (car vous n'avez pas à vous soucier d'un changement dans un domaine de l'application en cassant un autre).

Answer 2

Il vous permettra d'économiser beaucoup de temps pour tout projet qui n'est pas infiniment petit, où j'définir infiniment petit que moins de quelques milliers de lignes de code (selon la langue).

La raison en est que, une fois que vous avez passé de super petits projets, chaque changement ou mise à jour devient plus difficile de la plus étroitement couplé elle est. Étant faiblement couplé vous permet de continuer à aller de l'avant, l'ajout de fonctionnalités, corriger des bugs, etc.

À un certain point, je pense que tout le programme devient un cauchemar à maintenir, mettre à jour et ajouter sur. Le plus faiblement couplées, la conception est, le plus loin que ce point est reporté. Si elle est étroitement couplé, peut-être après environ 10 000 lignes de code, il devient difficile à maintenir, en ajoutant quelques fonctionnalités devenu impossible sans essentiellement de réécriture à partir de zéro.

Étant faiblement couplés lui permet de croître à 1 000 000 - 10 000 000 de lignes de code, tout en étant toujours capable de faire des modifications et ajouter des nouvelles fonctionnalités à l'intérieur d'un laps de temps raisonnable.

Ces chiffres ne sont pas censés être pris à la lettre comme on vient de faire, mais pour vous donner une idée de l'endroit où il devient utile.

Si vous n'avez jamais besoin de mettre à jour le programme et il est assez simple alors bien sûr, c'est bien d'être étroitement associés. Il est même bon de commencer de cette façon, mais de savoir quand il est temps de séparer les choses, mais vous avez encore besoin d'une expérience d'écriture faiblement couplé code pour savoir à quel moment il devient bénéfique.

Entreprise Fizzbuzz est une intentionnellement humoristique exemple de la façon dont il est possible d'aller à la mer avec overengineering, et non pas chaque projet est besoin de le même niveau de découplage.

MVC est généralement considéré comme un bon point de départ parce que la plupart des projets devenir assez grand pour être utile. Lorsque le projet devient plus grande, que le niveau de découplage n'est pas suffisant, et le M doit être divisée en plusieurs couches de lui-même, et ainsi de suite. Il n'y a pas une seule taille convient à tous, mais MVC est une bonne quantité de découplage pour la plupart des projets.

Answer 3

Sur le papier, il y a de nombreux avantages du couplage lâche, mais dans la pratique, il est difficile de faire droit à mon humble avis. Voici quelques avantages:

• Les systèmes peuvent évoluer indépendamment en termes de cycle de vie.

• Les systèmes peuvent être écrits dans des langues différentes, et, finalement, de fonctionner sur différents Systèmes d'exploitation.

• Les systèmes peuvent (et devraient) être construit par les différentes équipes. Vous pouvez externaliser le développement de systèmes. C'est en fait presque le seul moyen à l'échelle d'un logiciel organisation de développement.

Voici quelques inconvénients cependant:

• C'est plus de travail au début, et si vous ne le faites pas bien, vous pouvez ne jamais voir les avantages.

• La définition d'Api/Contrats est assez difficile et nécessite des développeurs très expérimentés. C'est facile à faire au début, mais c'est dur sur le long terme.

• La généralisation du couplage lâche peut en effet conduire à la dactylographie partout. Au lieu d'utiliser clairement définis significative des objets, vous pouvez observer une augmentation dans l'utilisation de l '"objet" ou des paramètres de type de retour, de types génériques ajouté à chaque classe ou interface. Le mauvais effet de cette est le développeur moyen sera probablement ajouter sauvage des opérations de transtypage partout, en supposant que les types sur les deux côtés de la soi-disant systèmes faiblement couplés.

• Certains le couplage de techniques sont basées sur la généralisation des interfaces définition, avec l'intention d'éviter la dépendance directe. Souvenir d'une interface est censé être gravé dans la pierre, une fois définies et publiées. Maintenant, ce n'est pas vraiment ce que j'appelle le couplage lâche. Un .NET de la classe, en tirant parti de l'équipe et des techniques telles que la surcharge de la méthode peut être un meilleur couplage de l'instrument. Donc, le problème, avec ces interfaces et des usines partout il va entraîner une multiplication des types, des assemblées, des cas de test, etc... et tout simplement plus de travail et de la complexité en bas de la route. Au lieu de simplifier les choses, au lieu de construire un système, vous devrez construire des de nombreux. "un niveau N système est N-fois le travail" :-)

• Le couplage d'une certaine manière contourne l'un des outils les plus puissants jamais créés: le compilateur C# ou autres). Et c'est tout le but de ce fait, mais il a certainement quelques inconvénients, car tous les travaux sur le terrain le compilateur était en train de faire (vérification de type, etc...) devra être fait ailleurs (tests), et qui aura un coût.

• Beaucoup de dehors-de-le-boîte à outils ne fonctionnera probablement pas plus. Vous ne serez pas en mesure d'utiliser des choses comme Visual Studio "Aller À" Définition " ou "Trouver Toutes les Références".

Answer 4

Une architecture faiblement couplée vont vous aider lorsque votre application a besoin de changer ou de se développer. Et tout non-trivial application aura éventuellement besoin de changer ou de se développer.

Si vous design avec une architecture faiblement couplée, seulement quelques parties de la demande doit être affectée lorsque les besoins changent. Avec un trop serré couplé de l'architecture, de nombreuses parties aurez besoin de changer, et il sera difficile d'identifier exactement quelles parties seront touchés.

L'un des principaux avantages de l'ATS, à mon avis, c'est qu'à l'aide de promouvoir une architecture faiblement couplée.

Answer 5

Avantages:

• Évolutivité - vous permet d'étendre une couche d'accès à la base de données
• Permutabilité - par exemple, le code du fournisseur de messagerie
• Maintenabilité - changez simplement le code en un seul endroit
• Facilité de configuration des tests unitaires - vous pouvez simuler des objets comme votre base de données

Inconvénients:

• Plusieurs lignes de code supplémentaires peut-être
• Quelques classes d'interface supplémentaires