Design Patterns: Besoin d'aide à comprendre ce concept et son application à mon projet

Question

Les derniers jours, je l'ai fait beaucoup de recherches en utilisant l'approche DAL / BLL / UI sans une compréhension claire de la façon dont il appliquera à mon projet. Dans le passé, je l'ai laissé la BLL connecter mon interface utilisateur directement à l'accès aux données couche (LinqToSql dbml). Mais, je ne pense pas que ce soit une bonne idée où je travaille maintenant (ou peut-être même dans le passé) parce que nous avons beaucoup d'applications différentes et je voudrais utiliser le même DAL / BLL car ils sont construits.

Ma question est, comment l'aide BLL moi, dans la plupart de mes applications, tout ce que je fais vraiment est d'utiliser le LinqtoSqlDataSource / GridView pour se connecter à mon DataContext pour prendre soin de toutes les mises à jour / modifier, etc. De plus, chaque nouvelle application Web, à un certain niveau, exigent des changements uniques au DAL / BLL pour obtenir les données ont besoin, éventuellement affecter d'autres applications utilisant le même DAL / BLL. Est-ce réutilisation du DAL / BLL la bonne façon de le faire ou que je manque quelque chose?

Je pense que le BLL vient quand je dois construire, par exemple, un cours de sécurité pour les différentes applications Web qui seront construits. Mais, quand j'utilise le Linqtosqldatasource, pourquoi aurais-je pris la peine de le connecter au BLL?

DAL

• LinqToSQL dbml DataContext.
• Le fait d'utiliser le changement LinqToSQL comment je devrais utiliser cette conception?

BLL

• Sécurité pour divers site Web utilisé par la société.
• retour de requête DAL ce (?) Lors de l'utilisation LinqToSQLDatSource., Les fonctions qui gèrent divers ensembles de résultats (je suis vraiment pas sûr comment cela devrait fonctionner avec BLL, désolé si la question est claire)

UI

• Référence seulement le BLL?

Answer 1

Le DAL et BLL sont séparés par une différence subtile souvent, mais la clé; la logique métier. Sons moronically simple, mais permettez-moi d'expliquer davantage parce que les distinctions peuvent être très bien et pourtant l'architecture de l'impact d'une manière énorme.

En utilisant Linq2SQL, le cadre génère des objets très simples qui représentent chacun un enregistrement dans une table. Ces objets sont DTO; ce sont des classes lightwight, POCO (Object CLR Ol » ordinaire) qui ont seulement des champs. Le cadre Linq2SQL sait comment instancier et hydrate ces objets à partir de données DB et, de même qu'il peut digérer les données contenues dans un dans SQLDML qui crée ou met à jour le dossier DB. Cependant, peu ou aucune des règles régissant les relations entre les champs de divers objets sont connus à ce niveau.

Votre modèle de domaine réel devrait être plus intelligent que cela; au moins assez intelligent pour savoir qu'une propriété sur un objet ordre nommé SubTotal doit être égale à la somme de tous les ExtendedCosts de tous OrderLines et, de même, ExtendedCost devrait être le produit du prix unitaire et la quantité. Dans de nombreux programmes modernes, votre domaine fait partie de votre BLL, au moins dans cette mesure. Les objets créés par Linq2SQL devraient probablement pas savoir tout cela, surtout si vous n'êtes pas persistez ou subtotale ExtendedCost. Si vous comptez sur la Linq2SQL DTO, vous avez vous-même essentiellement lié à ce qu'on appelle un modèle de domaine anémiques, qui est un anti-modèle connu. Si l'objet de domaine ne peut se maintenir une cohérence interne au moins, alors tout objet qui fonctionne avec l'objet de domaine doit faire confiance pour garder cette façon, exigeant que tous ces objets de connaître les règles qu'ils ne devraient pas avoir à.

L'interface utilisateur doit connaître le domaine, ou si vous préférez, il devrait savoir d'une manière abstraite pour obtenir les données du domaine à des fins de lecture-écriture (généralement encapsulées dans des objets appelés contrôleurs, qui fonctionnent avec la couche de domaine et / ou Linq2SQL). L'interface utilisateur ne devrait pas avoir à connaître la base de données dans un programme de taille moyenne ou plus; soit les objets de domaine peuvent se hydrater avec une référence à des objets dans le DAL, ou ils sont produits par des objets personnalisés dans le DAL que vous créez pour faire l'hydratation, qui sont ensuite remis au contrôleur. Le modèle ADO connecté et avec Interop GridViews est admirable, mais il ne permet pas d'abstraction. Dites que vous vouliez insérer une couche de service Web entre le domaine et l'interface utilisateur, pour permettre l'interface utilisateur de se trouver sur une application mobile qui a travaillé avec des données dans votre entrepôt. Il faudrait reconstruire votre interface utilisateur, parce que vous ne pouvez plus obtenir des objets de Linq2SQL directement; vous les obtenez des services Web. Si vous aviez une couche contrôleur qui a parlé à Linq2SQL, vous pouvez remplacer cette couche avec des contrôleurs qui a parlé aux services Web. Cela ressemble à une différence mineure; vous avez toujours changer quelque chose. Mais, maintenant que vous utilisez la même interface utilisateur EXACTEMENT sur les applications mobiles et de bureau, de sorte que des modifications à cette couche ne doivent pas être fait deux fois juste parce que les deux couches obtenir des données de différentes façons.

Answer 2

Ceci est une grande question que j'ai ressassant avec notre application de catalogue pour un an. Une instance spécifique pour moi pourrait vous aider avec le motif.

J'ai une page pour afficher le contenu d'un panier. Dans les premiers jours »cette page avait une grille peuplée par les résultats d'une procédure stockée SQL qui, étant donné le numéro de commande, une liste des articles dans le panier.

Maintenant, j'ai un objet BLL « panier » qui contient une collection d'objets « rangée ». La grille est la même, mais la source de données est les lignes du panier.

Pourquoi est-ce que je fais cela? Dans un premier temps, pas becuase de tous les modèles de conception de fantaisie. J'avais tant de cas particuliers à poignée en fonction de champs de chaque ligne et moi avons eu d'autres endroits où je devais montrer les mêmes données de panier-contenu, il vient de faire plus de sens pour construire les objets. Maintenant, une charge à partir d'un panier dépôt et mes pages ont aucune idée de ce que ce référentiel ne. Heck, pour les tests, ses données de panier codées en dur.

Le panier utilise ensuite un référentiel pour charger les lignes. Chaque ligne a une logique à se maniuplate, ne sachant pas où les données venaient.

Si tout va bien qui aide?