Tutorial :Data Access Layer



Question:

how we can create a generic data access layer that can be used by any asp.net application using different datasource provider or webservices?

Can we create data access layer for application that consumes webservice?


Solution:1

You might look into the Repository Pattern. Repository is a facade that presents persisted objects as though they are in a collection in memory. Whichever provider you choose to get data is hidden behind the Repository interface.

IRepository with LINQ to SQL

Code Project Tutorial

A sample by Fredrik Kalseth


Solution:2

You have plenty of options! :-)

You mention you want to use the data access layer (DAL) from asp.net and web services. No problem.

Basically, what you need to figure out is a basic design you want to follow, and encapsulate the DAL into its own assembly which can be used / referenced from various consumers.

There are numerous ways of doing this:

  • create a Linq-to-SQL mapping for your tables, if you're using SQL Server as your backend, and use the Linq-to-SQL entities and methods
  • create a repository pattern (for each "entity", you have an "EntityRepository" class, which can be used to retrieve entities, e.g. EntityReposity.GetByID(int id), or EntityRepository.GetByForeignKey(string fk) or whatever
  • use some other means of accessing the data (NHibernate, your own ADO.NET based mapper)
  • you could actually also use webservice calls as your data providers

Your biggest challenge is to define a standard way of doing things, and sticking to it.

See some articles - maybe they'll give you an idea:


Solution:3

Try the tutorials at www.asp.net:

DataAccess


Solution:4

Woah, there are a ton of resources out there. Best advice to start is to find a pattern that you feel comfortable with and stick to it for the project, there is nothing worse then changing your mind 3/4 the way in.

One that I have found and like to use is the Repository or Provider patter. The Repository pattern just makes sure you have standard access to repositories, like your store catalog or CMS system. You create an interface that in my case expose sets of IQueryable the object or the data model are just standard c# classes with now extra fluff POCO (Plain Old CLR Objects).

public interface ICMSRepository {      IQueryable<ContentSection> GetContentSections();      void SaveContentSection(ContentSection obj);  }  

Then just implement the interface for your different providers, like a LINQ to SQL context, making sure to return the POCO objects as queryable. The nice thing about this is that you can then make extension methods off of the IQueryable to get what you need easily. Like:

public static IQueryable<ContentSection> WithID(this IQueryable<ContentSection> qry, int ID) {      return from c in qry select c;  }    //Allow you to chain repository and filter to delay SQL execution  ICMSRepository _rep = new SqlCMSRepository();  var sec = _rep.GetContentSections().WithID(1).SingleDefault();  

The nice thing about using the Interface approach is the ability to test and mock it up or dependency inject your preferred storage at run time.

Another method I have used and is used in the ASP.Net framework a lot is the Provider model. This is similar except instead of an Interface you create a singleton abstract class, your implementations on top of the abstract class will then define the storage access means (XML, Flat file, SQL, MySql, etc). The base abstract class will be also be resonsible for creating it's singleton based on configuration. Take a look at this for more info on the provider model.

Otherwise you can look at this similar question.


Solution:5

IRepository of T is general good approach. This Interface should expose GetAll, GetByID, Insert, Delete and Submit methods.
But it's important to keep your business logic out of Repository class, and put it to custom logic/service class.
Also, if you return IQueriable in your GetAll method, what you can often see in various implementation of IRepository, UI layer can also query against that IQueriable interface. But querying of object graph should remain in Repository layer. There's a lot debate around this issue.


Solution:6

Look at using the Interfaces:

IDbConnection IDbCommand IDbDataAdapter IdataReader


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »