Dans une application N-Tier, vous devez avoir une couche logique métier et une couche d'accès aux données. Est-il mauvais d'avoir simplement deux assemblys: BusinessLogicLayer.dll et DataAccessLayer.dll pour gérer toute cette logique? Comment représentez-vous réellement ces couches. Il semble stupide, comme je l'ai vu, d'avoir une bibliothèque de classes BusinessLogic contenant des classes telles que: CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc. appelant chacune leur cousin nommé de manière appropriée dans la bibliothèque de classes DataAccessLayer, à savoir CustomerDataAccess.cs, OrderDataAccess .cs.Architecture N-Tier générale Question
Je veux créer une application web en utilisant MVP et il ne semble pas si sec et aussi sec que celui-ci. Il y a beaucoup d'opinions sur l'endroit où la logique métier est supposée être mise en MVP et je ne suis pas sûr d'avoir trouvé une réponse vraiment géniale pour le moment. Je veux que ce projet soit facilement testable, et j'essaie d'adhérer aux méthodologies TDD du mieux que je peux. J'ai l'intention d'utiliser MSTest et Rhino Mocks pour les tests.
Je pensais à quelque chose comme ce qui suit pour mon architecture:
j'utiliser LINQ to SQL pour parler à la base de données. Services WCF pour définir des interfaces de contrat de données pour la couche logique métier. Ensuite, utilisez MVP avec ASP.NET Forms pour l'interface utilisateur/BLL.
Maintenant, ce n'est pas le début de ce projet, la plupart des choses LINQ est déjà fait, donc il est bloqué. Le service WCF remplacerait l'assembly DataAccessLayer existant et l'interface utilisateur/BLL remplacerait l'assembly BusinessLogicLayer etc.
Ce genre de sens est logique dans ma tête, mais il devient vraiment tard. Quelqu'un qui a voyagé sur ce chemin a-t-il des conseils? Bons liens? Avertissements?
Merci!
Merci Tom Tom, ne tenez pas compte de mon poste autre que ma planification. Je vais prendre une copie du livre que vous avez mentionné. –
Merci pour votre réponse. C'était un peu dur mais je suppose que c'est un signe que vous avez des sentiments si forts. Cependant, s'il vous plaît noter que ce n'est pas mon design. Je pensais que la WCF serait une bonne voie à suivre. Cela semblait aller, mais vous avez raison, cela ajouterait des frais inutiles. Pour répondre à votre "Daily WTF", nous avons un assembly LINQ qui contient nos entites et le DAL contient notre API pour la couche LINQ. Mais alors une grande partie de la logique BLL semble juste être des talons appelant le DAL. Ces couches pourraient probablement être fusionnées en une seule couche de service (d'où ma pensée de WCF. * Sigh * – mikesigs
La réponse était honnête et correcte.) Toute difficulté dans la réponse semble être justifiée Qu'est-ce que vous avez besoin d'une couche de service * pour *? Pourquoi avez-vous besoin d'utiliser un canal de communication? Pourquoi votre logique métier n'est * pas * dans vos objets de modèle? Pourquoi insistez-vous pour faire référence à LINQ to SQL comme "DAL" alors qu'il est censé être votre modèle de domaine transparent? Il y a beaucoup trop de choses là-dedans, et pour autant que tout le monde sache, il n'y a pas de raison pour cela, tout cela peut avoir un sens dans votre tête, mais je ne comprends pas pourquoi vous voudriez faire face à tout cela. – yfeldblum