Y a-t-il des raisons négatives d’utiliser une solution N-Tier ?

Question

Je suis assez nouveau dans mon entreprise (2 semaines) et nous lançons une nouvelle plate-forme pour notre système en utilisant .NET 3.5 Team Foundation de DotNetNuke.Notre « architecte » suggère que nous utilisions un seul projet de classe.Bien sûr, je reviens sur une architecture "3 niveaux" (projets de classe Business, Data, Web).

Y a-t-il des inconvénients à utiliser cette architecture ?Les avantages seraient la séparation du code des données, en gardant les objets de classe éloignés de votre code, etc.

Answer 1

Je suppose qu'un inconvénient assez important est que le volume supplémentaire de code que vous devez écrire, gérer et maintenir pendant un certain temps. petit le projet est peut-être tout simplement exagéré.

Tout dépend de ce qui convient à la taille du projet, à la durée de vie prévue du projet final et au budget !Parfois, même si faire les choses « correctement » est attrayant, faire quelque chose d'un peu plus « léger » peut être la bonne décision commerciale !

Answer 2

il faut généralement plus de temps à une équipe inexpérimentée pour construire un système à 3 niveaux. C'est plus de code, donc plus de bugs.Mais je me fais juste l'avocat du diable.

Answer 3

Je ferais pression pour l'approche à plusieurs niveaux, même s'il s'agit d'un petit projet.Si vous utilisez un outil ORM comme codesmith + nettiers, vous pourrez rapidement configurer les projets et développer du code qui résout rapidement vos problèmes commerciaux.

Cela me tue lorsque vous démarrez un nouveau projet et que vous passez des journées assises autour de rouets à parler de la façon dont «l'architecture» devrait être architecturée.Vous voulez passer du temps à résoudre le problème de votre entreprise, et non à résoudre des problèmes que d’autres personnes ont résolus pour vous.Utiliser un ORM (peu importe lequel, choisissez-en un et respectez-le) pour vous aider à obtenir une traction initiale vous aidera à rester concentré sur les objectifs du projet et à ne pas vous distraire en essayant de résoudre les problèmes « d'architecture ».

Si, en fin de compte, l'architecte souhaite adopter l'approche d'un seul projet, il n'y a aucune raison pour que vous ne puissiez pas créer un dossier app_code avec un dossier BLL et DAL pour séparer le code pour l'instant, ce qui vous aidera à passer à un Solution à N niveaux plus tard.

Answer 4

Parce que tu veux le aptitude de pouvoir distribuer les couches sur différents niveaux physiques (j'utilise toujours « niveau » pour physique et « couche » pour logique), vous devriez réfléchir à deux fois avant de tout mettre dans une seule classe car vous avez des refactorisations majeures à faire si ou quand vous devez commencer à distribuer.

Answer 5

Comme pour toute chose, l'abstraction crée de la complexité, et la complexité de la réalisation de N niveaux doit donc être correctement justifiée. Par exemple, N niveaux profite-t-il réellement au système ?Là volonté être de petits systèmes qui fonctionneront mieux avec N-niveaux, même si beaucoup d'entre eux ne le feront pas.

De plus, même si votre système est petit pour le moment, vous souhaiterez peut-être y ajouter plus de fonctionnalités plus tard - sans passer à N niveaux. pourrait constituent une sorte de dette technique de votre part, il faut donc être prudent.

Answer 6

Le seul inconvénient est la complexité, mais il est vraiment difficile d'ajouter des objets de domaine et de les lier à une liste plutôt que d'utiliser un ensemble de données.Vous n'avez même pas besoin de créer trois projets séparés, vous pouvez simplement créer 3 dossiers séparés dans l'application Web et attribuer à chacun un espace de noms tel que YourCompany.YourApp.Domain, YourCompany.YourApp.Data, etc.

Le gros avantage est d’avoir une solution plus flexible.Si vous commencez à écrire votre application en tant qu'application centrée sur les données, en couplant fortement vos pages de formulaires Web à des ensembles de données, vous finirez par faire beaucoup plus de travail plus tard en migrant vers un modèle plus centré sur le domaine à mesure que votre logique métier gagne en complexité.

Peut-être qu'à court terme, vous vous concentrerez sur une solution simple en créant des objets de domaine très simples et en les remplissant à partir d'ensembles de données, vous pourrez ensuite leur ajouter une logique métier si nécessaire et créer un ORM plus sophistiqué si nécessaire, ou utiliser nhibernate.