Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0DAL desing using DAAB 4.0DAL desing using DAAB 4.0
Previous
 
Next
New Post
10/21/2008 9:12 PM
 

 Hi,

 
I'm working on a .Net 3.5 web application.It has various modules say for example Customers,Orders,etc....
I need to a design Data  Access Layer (DAL) for the same using Enterprise Library 4.0 (using Data Access Application block or DAAB)  to connect to SQL Server 2008.
 
Here is how i plan to go about it:
 
1.Have an interface called "IDataService".It will have members like "ExecuteReader()","ExecuteScalar()","ExecuteNonQuery()", "AddParams",etc...basically, this interface will almost look like that of DAAB.
 
2.Have a class called "DataService" which implements this interface.This class will act as a wrapper over DAAB and each of the method will use the corresponding method in DAAB internally. 
 
3.Have Business classes(or Data Containers) like Customer,Data, etc which will have properties mapping to their corresponding tables attributes in the database.
 
4.Have DAL classes for each module like CustomerDataService, OrdersDataService, etc.Each of these classes will have constructor code in which I will instantiate DataService class as below:
IDataService dataService= new DataService()
 
Also, each of these classes will have methods like:
GetCustomerDetails()
AddCustomer()
RemoveCustomer()
UpdateOrder etc.
 These methods will internally use "dataService" object to make any operation on the database ExecuteReader,ExecuteNonQuery, etc
 
5.Have a mapper class for each  module like "CustomerMapper","OrderMapper",etc.
These class will take datasource(for example IDataReader) as input and would fill in the data in the generic collection (List<Customers>,List<Orders>).
And these mapper classes will be internally called by the corresponding Dataservice class to return the type-safe collection to the calling client. 
 
6.Have a helper class like DbHelper which will do tasks like "handling DBNull cases","storing stored procedure names",etc.
 
7.DataService classes will be inturn used by the BusinessLogic layer classes...ie CustomerBusiness,OrdersBusiness,etc.
 
8.Business Logic layer will return the collection to the presentation layer .
 
Does this design make any sense?What are the advantages/disadvantages of this approach?
 
The advantage I could think of this approach is all DataService classes will alway program against the interface "IDataService" without needing to know how "DataService" class is implemented internally.So tomorrow,if i remove DAAB and use another API inside my DataService class, the client code need not change.
Also,I can add any method in my IDataService interface which is not present in DAAB....for example BatchUpdate()....
 
Please correct me if i am wrong.
 
Thanks in advance!
 
Cheers,
Simon
 
New Post
10/22/2008 5:54 AM
 

Hi,

The logic sounds OK. The advantages of such a setup are pretty clear. You seperate your businesslogic form your data layer so you can use the same datalayer to fill all of your business objects. However, and i might just be misreading your post, is this not app. what DotNetNuke already has built in?

If you create a custom module with the starterkit (through one of the tutorials findable in this forum) you get a sqldataprovider.cs which uses the sqlhelper class from the Microsoft.ApplicationBlocks.... to connect to the DB and execute a SP or such  through the various execute methods. It also creates a dataprovider.cs (inherited by the sqldataprovider class) with the abstract methodes to make the sqldataprovider methods available to the business logic, an *info.cs class for the properties and a *controller.cs class for handling the methods you call from your code. The controller class loads a dataprovider.instance (comparable with your DataService) which maps to the appropriate method in the sqldataprovider (through inheritance) and returns an IDatareader mapped to your custom type which most oftenly is your info class. If this is already built in, why create one of your own?

Alexander

 

 
New Post
10/23/2008 8:27 AM
 

This sounds like the current DotNetNuke DAL to me.

DAL & DAL+

My question is, do you plan to use more than one type of database for your module? If you don't are you sure you want to do it this way? If you do, the Core DotNetNuke site will need to have a provider created (or purchased if using Oracle) that implements the required provider methods of the DotNetNuke DAL.

If you do not plan to support databases other than SQL, consider using Linq to SQL

Using LINQ to SQL

This would provide a significant cost savings by reducing development time.



Michael Washington
http://ADefWebserver.com
www.ADefHelpDesk.com
A Free Open Source DotNetNuke Help Desk Module
 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0DAL desing using DAAB 4.0DAL desing using DAAB 4.0


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out