Comment strictement suivez-vous l'architecture n-tier et la séparation des préoccupations entre les couches dans vos projets?

Question

Je suppose que la plupart des développeurs ont une idée de l'architecture multi-couches. Nous avons DAL (Couche d'accès aux données), nous avons BLL (couche de logique métier) et quelque part vers la fin de la route, nous avons notre interface utilisateur. Si vous avez un projet qui suit en quelque sorte ces principes, gardez-vous (ou du moins essayer) de garder / mettre les choses là où ils appartiennent conceptuellement? Je suis particulièrement intéressé par les grandes applications de l'entreprise où vous travaillez ensemble avec beaucoup d'autres personnes. Il est clair que vous pouvez faire ce que vous voulez avec votre projet de jouet privé, inventer toute sorte d'une architecture et de s'y tenir. Il est pas si facile avec de grands projets où beaucoup de gens ont contribué au logiciel ou désordre général.

Par exemple, j'arrivé de voir des choses comme des composants de l'interface utilisateur qui vont directement à la base de données de récupérer quelques données « manquantes » supplémentaire qui BL ne fournit pas, aussi à la fois l'interface utilisateur et BL travailler avec des éléments de bas niveau comme les champs de table où à mon avis ils devraient déléguer ces opérations au niveau inférieur à savoir DAL. Il était particulièrement triste quand après avoir discuté des choses avec le gars de développeur senior, j'ai vu qu'il ne voyait pas de problème avec du tout.

Nous pouvons bien sûr me assumer et celui qui partage mon point de vue sont tout simplement être perfectionnistes, mais j'ai vu clairement une conséquence très disadvantegous en ce qu'il m'a fallu de longues périodes de temps dans certaines de mes tâches de tracer toutes les « parallèles » itinéraires que les données de voyage à destination et à partir de la base de données et d'identifier quiconque et de quelle manière peut maintenant être affectée par la nouvelle fonctionnalité que je mis en œuvre. La façon dont je le vois, ceux-ci sont encore augmenté les coûts de développement / entretien des économies quand surpondération quelqu'un a décidé de pirater rapidement les choses et fermez la tâche le plus rapidement possible.

Êtes-vous des projets « pur » ou ils ont abandonné l'idée de garder la ligne claire entre les couches il y a longtemps? Si vous garder encore bon, comment vous traitez avec des collègues qui ne comprennent pas ces choses ou ne se soucient pas de les construire simplement des solutions « sur mesure » et hacks hacking tout le temps? Ou à un moment donné dans le temps vous avez cessé de se battre avec le moulin à vent et accepté comme votre punition ?. EDIT: Un peu surpris que pas beaucoup de gens se sont intéressés à ce problème. Est-ce que le signe le plus ne se soucient pas?

Answer 1

Le plus compliqué notre application obtient, la séparation plus importante des préoccupations devient.

A 100 klocs, l'application a été un gros blob, tant le code de l'entreprise dans les classes forment comme partout ailleurs et remet en forme les méthodes des classes d'affaires. Avec beaucoup de pleurs et des grincements de dents, nous avons séparé la logique métier de la logique d'affichage. Toute classe qui avait besoin d'informer l'utilisateur de ses progrès a soulevé un événement qui a été coulé par l'interface utilisateur. Et, pendant un certain temps, tout était bien dans le monde.

Environ 200 klocs, nous avons ajouté une couche de données. L'architecture de notre application a été telle que la plupart de nos données ont été traitées dès qu'il est entré et immédiatement mis au rebut. La plupart des informations de configuration a été stockée dans l'application tierce qui nous ont partagé une relation symbiotique. Mais, les paramètres ont commencé à accumuler dans toutes sortes de coins impairs. Nous avons fini avec trois systèmes de gestion de configuration, tous étroitement tissées dans la logique métier. Avec une vaste réécriture, nous avons pu séparer les informations de configuration dans sa propre couche et le traitement des données en continu dans une autre couche.

Près de la ligne 250 Kloc, nous avons décidé de mettre fin à notre relation avec le fournisseur tiers et faire notre application autonome. Nous avons commencé une réécriture massive et, pour la première fois, a ajouté une base de données réelle à notre application. Parce que nous avions des lignes claires entre les informations en continu, le stockage de données et la logique métier, ce fut une intégration assez transparente.

Maintenant, approchant 500 klocs, nous allons de l'application à une architecture basée sur la grille. Pas l'interface utilisateur ne sera séparé de la logique métier sur un autre ordinateur, le calcul réel des devis et des commandes que l'application Libère sera équilibrée et répartie pour maximiser l'efficacité. Ce serait impossible sans une architecture n-tier.

A chaque étape de croissance, nous avons été soit aidé par une séparation nette ou entravées par notre propre embrouillamini de la communication, les données, les entreprises et l'interface utilisateur. Il n'y a probablement pas été une préoccupation plus importante que cette séparation dans la création de cette application.

Answer 2

C'est une grande question! Quelque chose chaque développeur ASP.Net doit penser. Vous aurez probablement beaucoup de réponses, je vous encourage ces idées de base de sens commun.

- Pensez à la simplicité et la rapidité de livraison comme une partie d'une architecture « réussie », non seulement « pureté ». Essayez d'équilibrer entre la tenue aux idéaux architecturaux, et d'être pratique.

- En général, il semble logique de diviser le code en en couches que vous mentionnez. Je suggère cependant qu'il pourrait être laissé dans la page s'il est plus simple / rapide pour la logique spécifique à la page, - pourquoi créer des objets métier génériques pour le code qui est juste utilisé dans un seul endroit. Comme il a été dit: « L'optimisation prématurée est la racine de tout le mal. ».

-. Gardez les couches et la complexité au minimum pour réduire le codage du temps et d'améliorer la lisibilité et la maintenabilité

Il y a beaucoup de puristes sur ce site qui aiment faire de l'architecture pour le site de l'architecture - utiliser l'architecture comme un outil pour fournir une solution à un problème d'entreprise, et pas seulement comme une forme d'art pour son propre intérêt, que ce soit un outil utile plutôt que de vous utiliser.

Answer 3

Gardez les préoccupations séparées. Il est très très important. Ne pas mélanger avec l'interface utilisateur Biz et Biz avec couche de données. Travailler avec l'abstraction. Travailler avec l'abstraction rend également le test (tests unitaires) plus facile (les Mock). Je garde strictement chaque couche où il appartient. Rappelez-vous que le coût le plus élevé de tout projet est-il est maintainance. Si vous mélangez les préoccupations alors maintainance est devenu un cauchemar va.

Answer 4

Nous avons une application Winforms, et une application ASP.NET. Ils utilisent tous deux le même projet Business Objects (environ 140 classes).

Le projet Winforms se compose d'environ 350 formulaire et des contrôle de l'utilisateur, et très peu (<10) de ces métadonnées ont besoin eux-mêmes à partir de la base de données.

Le projet ASP.NET a environ 100 pages .aspx.

Nous avons une couche d'accès aux données composé de 5 classes, qui se concernent avec ADO.NET, fils et transactions. Ils convertissent les demandes de Business Objects dans les appels SQL Server.

Les couches de l'interface utilisateur (à l'exception des quelques classes qui ont besoin des métadonnées sur la forme de calibrage) ne pas accès à la base du tout. Même les quelques exceptions passent par le DAL comme toute autre chose.

La couche d'affaires ne sait rien sur le fonctionnement interne de la couche d'accès aux données, et quand il a besoin de données, ne jamais appelle des méthodes publiques sur les classes DAL.

Je ne suis pas du tout un fondamentaliste quand il vient à ce genre de chose, mais nous avons jamais eu besoin de couper les coins ronds sur celui-ci.

Donc en bref, 100% pur. Il est tout simplement toujours mieux élaboré faire droit.

Nous aurions dû avoir un enfer d'une bonne raison de se éloigner de maintenant.

Answer 5

Code Monkeys et les puristes sont un peu comme tout autre extrémiste dans la vie.

Nous avons l'aile extrême droite et extrême gauche. Très peu de gens sont exactement l'un ou l'autre, et ils trouvent un bon milieu où ils sol sont assis. Si ce n'était pas pour les extrémistes que nous ne saurions pas où les limites se trouvent.

En ce qui concerne le code I façon continue. J'écoute la façon dont les puristes de le faire. Je vois les singes de code vaquent à leurs méthodes. J'utilise mon expérience pour choisir un moyen qui me donne la bonne quantité de flexibilité et de gestion ainsi que le temps que je dois produire et la quantité d'argent que je vais réellement faire pour le faire.

Answer 6

Plus le code, plus la durée de vie, les plus différentes personnes travaillent sur le code (deux en même temps ou pendant la durée de vie) plus importante séparation en couches, elle est. Au début, il semble être un peu plus de travail inutile, mais à long terme, il paie pour lui-même plusieurs fois.

En ce qui concerne l'application de la séparation: C'est pourquoi a besoin de votre programmeur principal ou architecte technique de bonnes compétences générales ainsi que des compétences purement techniques. Vous pouvez essayer d'appliquer la séparation technique (voir ci-dessous), mais à la fin, vous devez convaincre (ou contraindre) vos développeurs de garder la grande image propre.

Mais cela ne veut pas dire que les moyens techniques pour faire respecter la séparation ne servent à rien. En fait, je trouve que veiller à ce que « transfrontalier appelle » sont assez difficiles à faire va rendre les gens passent plus de temps à penser à ce qu'ils ont vraiment besoin dans la interface transfrontalière, la création d'interfaces plus propres. Peu importe si la difficulté est d'ordre technique (parce que vous devez utiliser COM ou CORBA) ou autre chose (vous devez remplir un formulaire de la page 7 en triple exemplaire).