Conception DAL utilisant DAAB 3.5/4.0

Question

Je travaille sur une application web .Net 3.5.Il a différents modules disent par exemple Clients, Commandes, etc .... J'ai besoin d'un design Data Layer (DAL) pour la même chose en utilisant Enterprise Library 4.0 (en utilisant Data Access Application block ou DAAB) pour se connecter à SQL Server 2005. Voici comment je prévois de le faire:

• Avoir une interface appelée "IDataService" .Il aura des membres comme "ExecuteReader()", "ExecuteScalar()", "ExecuteNonQuery()", "AddParams", etc ... fondamentalement, cette interface ressemblera presque à celle de DAAB.

• Avoir une classe appelée "DataService" qui implémente cette interface. Cette classe agira comme une enveloppe sur DAAB et chacune de la méthode utilisera la méthode correspondante dans DAAB en interne.

• Avoir des classes Business (ou Data Containers) comme Customer, Data, etc. qui auront des propriétés correspondant à leurs attributs de tables correspondants dans la base de données.

• Avoir des classes DAL pour chaque module comme CustomerDataService, OrdersDataService, etc.Chacune de ces classes aura un code constructeur dans lequel j'instancierai la classe DataService comme suit: IDataService dataService = new DataService() En outre, chacune de ces classes ont des méthodes telles que: GetCustomerDetails() AddCustomer() RemoveCustomer() UpdateOrder etc. Ces méthodes utiliseront en interne objet "DATASERVICE" pour faire une opération sur la base de données ExecuteReader, ExecuteNonQuery, etc

• avoir une classe mappeur pour chaque module comme "CustomerMapper", "OrderMapper", etc. Ces classes utiliseront datasource (par exemple IDataReader) comme entrée et rempliront les données de la collection générique (List). Et ces classes de mappeur seront appelées en interne par la classe Dataservice correspondante pour renvoyer la collection de type sécurisée au client appelant.

• Avoir une classe d'assistance comme DbHelper qui fera des tâches comme «gérer les cas DBNull», «stocker les noms de procédure stockée», etc.

• Les classes DataService seront utilisées par les classes de couche BusinessLogic ... c.-à-d. CustomerBusiness, OrdersBusiness, etc.

• La couche logique métier renvoie la collection dans la couche de présentation.

Cette conception a-t-elle un sens? Quels sont les avantages/inconvénients de cette approche? L'avantage que je pourrais penser de cette approche est que toutes les classes DataService seront toujours programmées contre l'interface "IDataService" sans avoir besoin de savoir comment la classe "DataService" est implémentée en interne.So dans le futur, si je supprime DAAB et utilise une autre API dans mon Classe DataService, le code client n'a pas besoin d'être modifié. En outre, je peux ajouter n'importe quelle méthode dans mon interface IDataService qui n'est pas présente dans DAAB .... par exemple BatchUpdate() ...

Corrigez-moi si je me trompe.

Answer 1

On dirait que vous le compliquez comme il se doit. Peut-être prendre une étape à la fois aiderait.

DAL: Je ne vois pas les avantages d'avoir un emballage sur DAAB. IMO, DAAB est déjà un wrapper DAL. Wrapper over wrapper est contre-productif. Il devrait y avoir un seul DAL. C'est tout l'intérêt de DAL. ORM: Pour la classe de mappeur, vous devriez peut-être envisager d'utiliser Entity Framework ou NHibernate pour ORM. Coder votre propre ORM est fastidieux et difficile à maintenir lorsque le schéma évolue.