meilleure façon de faire référence à des objets d'affaires de la couche de présentation ..?

Question

Je veux développer une application d'entreprise qui comprend une couche de présentation WindowsForms, composants de niveau intermédiaire pour la logique métier et l'accès aux données, et une base de données MSSQL Server. composants de niveau intermédiaire doivent contenir des objets métier et seront appelés de la couche de présentation en utilisant .NET Remoting. Whitch est la meilleure façon (et pourquoi) pour faire référence à ces objets métier de la couche de présentation?

• A) Créer un projet de bibliothèque de classes, la mise en œuvre des objets d'affaires. Référence projet de la couche de présentation et la couche de niveau intermédiaire.
• B) Créer un projet de bibliothèque d'interface définissant les objets métier. Créer un projet de bibliothèque de classe qui implémente des interfaces. classe de référence de projet de bibliothèque de la couche de niveau intermédiaire. Interface de référence projet de bibliothèque de la couche de présentation.
• C) Créer des projets distincts de bibliothèque de classes pour niveau intermédiaire et la couche de présentation. Référence du projet correspondant de la couche de présentation.

Answer 1

Il n'y a probablement pas de coupe claire et réponse définitive à cela, cela dépend de ce que vous faites.

• sera souvent assez bon dans de nombreux cas. Pour les petits projets « app unique » il n'y a pas vraiment de raison pour laquelle vous ne pouvez pas référencer simplement la bibliothèque d'objets métier directement à partir de deux couches UI et BL. Il est certainement le plus simple, et parfois la simplicité est la meilleure.

• B est probablement le « meilleur », vous serez vos mises en œuvre réelle abstraction loin des changements si futurs sont possibles sans contrats de rupture, et les tests unitaires est plus facile si vous avez des interfaces. L'autre avantage est que vous ne trouverez pas trop difficile de passer de B à C dans l'avenir si vous trouvez qu'il est nécessaire.

• C est probablement excessif dans la plupart des cas. Cela dit, sur les grands projets que vous trouverez peut-être nécessaire. J'ai travaillé sur de grandes applications n-tier client-serveur qui ont eu jusqu'à trois ensembles indépendants d'objets de données. Un ensemble utilisé dans la couche de DA à la carte et stocker dans la base de données. Un deuxième ensemble de couches logiques d'affaires et de réseau pour le traitement et la transmission sur le réseau, et le troisième jeu dans le client pour la liaison à l'interface utilisateur. Il est utile d'envisager l'utilisation d'interfaces C, ainsi que des avantages d'abstraction.

Dans l'ensemble, sans savoir exactement votre domaine d'application ou de la portée -. B est un bon point de départ

Answer 2

Je l'ai vu trois approches fonctionnent bien.

Que peut parfois être bon est de commencer par A, l'augmentation de la complexité passer à B, C

Dans les projets simples les « objets métier » peuvent être inclus dans le même projet que la présentation et la persistance niveaux - bien que cela puisse paraître l'hérésie, la définition des objets en utilisant différents namespaces peut fournir une séparation suffisante entre les « couches ».

Vous voudrez peut-être reconsidérer l'utilisation de .NET Remoting - WCF est de loin une meilleure technologie et beaucoup plus facile à utiliser.