so many data access options, what to use?

I am an asp.net web application developer and I always have used Enterprise Library DAAB with stored procedures for data access with 4 seprate layers (presentation layer, custom types layer, business logic layer and data access layer).

My feeling is that this approach is wasting much time.

I have not worked with other ways of accessing data but sure there are many ways that save development time. While searching I read about these:

1. Data Adapters they generate whole DAL with stored procedures
2. Linq with different flavers
3. Entity Framework
4. Using data controls like SQLDataSource and Dynamic Data
5. Other mappers, code generaters and utilities

So much options and my little knowledge, I am confused in making decision what development patern I should adopt considering that my development may be fast, extendable, re-usable and up to the standard. Also I want to go for a way in which my code libr开发者_如何学运维aries can be used with other technolgies like silverlight, mvc framework, services if I ever need to use.

Kindly guide me and help.

thanks

For accessing relational databases such as SQL Server an Object Relational Mapper (ORM) is very useful. In the .NET space Entity Framework from Microsoft and the open source NHibernate are popular choices. I highly recommend trying one of these.

Entity Framework has drag-n-drop style designer support in Visual Studio and NHibernate has better code based configuration. I would recommend trying which ever of those options sounds best to you.

Coming from Enterprise Library and stored procedures you will quickly find how easy these tools make CRUD tasks, however like anything for more complex updating and querying there is a bit to learn.

You're already doing things with good practice. Anything that you move into will only make what you know go easier. Mix, match, use each option. Nothing will hurt you because the knowledge you gain will only make you more valuable.

There are tons of patterns to read and study (Adapter, Repository, MVP, etc). You have to decide which one works for you. It sounds like you are already layering your applications appropriately by segregating your business logic from your UI logic and you data access layer into a separate layer. Writing software is hard but you could go a step further and define base interface layers for your classes so you don't have to rewrite the same interface over and over, then you can just extend that interface further by adding to the available interfaces. That would save you some time.

You can also look at using the MVC# framework or the ASP.NET MVC framework from Microsoft. As far as your repository pattern, have you considered NHibernate?

Good luck.