Comment mon équipe doit-elle choisir entre les architectures à trois niveaux et à deux niveaux?

Question

Mon équipe discute de l'orientation future de nos projets. La moitié de l'équipe croit en une architecture pure à trois niveaux tandis que l'autre moitié préfère une architecture à deux niveaux.

Hypothèses du projet:

1. applications métiers de l'entreprise
2. logique métier nécessaire entre l'utilisateur et base de données
3. Validation des données nécessaires
4. (préféreriez services RESTful) Service axé sur
5. multi plan d'entretien annuel
6. soutenu des centaines d'utilisateurs

équipe 3 niveaux Favors:

1. couche Persistant < ==> couche de domaine < ==> couche d'interface utilisateur
2. limite de service entre la couche au moins persistante et couche de domaine. La couche de domaine peut avoir des limites de service entre elle et.
3. Traductions entre chaque couche (séparation DTO propre)
4. rouleau main de persistence à moins que nous pouvons trouver l'automatisation créative élégante

équipe 2 niveaux Favors:

1. Entity Framework + WCF Couche de service de données < ==> Couche d'interface utilisateur
2. Logique métier conservée dans les intercepteurs du service de données WCF
3. Traduction minimale entre les couches - favoriser un codage plus rapide

Voilà donc l'argument de haut niveau. Quelles considérations devrions-nous prendre en compte? Quelles expériences avez-vous eu avec l'une ou l'autre approche?

Answer 1

Il ya un temps et un lieu pour la conception initiale, et il ne peut être fait que par un architecte expérimenté qui connaît les tenants et les aboutissants de votre projet. Pour moi, s'il y a tout doute ou il pourrait aller de toute façon, je prends comme ça:

1. Commencez petit (une couche)
2. Utiliser développement piloté par une interface & bonne SRP, conception agile,
3. Une fois que vous avez un prototype de travail, avoir une session de refonte. Le choix devrait être beaucoup plus clair.

YMMV.

Answer 2

Je ne crois pas que les deux côtés soient réellement si éloignés.Il me semble que l'approche à deux niveaux cherche à mettre l'accent sur la présentation et à vouloir que les services fassent le gros du travail. Les services auront probablement encore un autre niveau impliqué pour l'accès aux données, c'est donc une autre approche à trois niveaux. C'est aussi celui que nous privilégions dans mon travail parce que faire les changements dans les services souvent ne nécessite aucun changement aux consommateurs, en supposant que nous maintenons la même interface. Tout ce qui est dit cependant, je pense que cela devrait être beaucoup plus bas sur la liste de priorités des choses à se préoccuper. Une approche à plusieurs niveaux ne va pas vous aider en soi. C'est la façon dont ces niveaux sont construits qui est important. Je pense qu'il est beaucoup plus important que tout le monde s'entende sur les pratiques de codage. Des choses comme l'injection de dépendance, la séparation des préoccupations, l'inversion du contrôle, les tests unitaires, le moquerie, etc. Ces choses sont tellement plus importantes que de se préoccuper du nombre de niveaux. Les gradins suivront naturellement une fois ceux-ci en place.