C# alternative or more current data access then Enterprise Libraries

Currently I basically add references to Microsoft.Practices.EnterpriseLibrary.Common .Data .ObjectBuilder

I find myself creating holding class like 'Product' then have another class that makes a list like Products : List

public class Products : List<Product>
{
    public Products()
    { }

    public void SelectAll()
    {
        Database db = DatabaseFactory.CreateDatabase();

            using (IDataR开发者_高级运维eader r = db.ExecuteReader(cmd))
            {
                while (r.Read())
                {
                    this.Add(new Product(Convert.ToInt32(r["PRODUCT_ID"]),
                                        r["NAME"].ToString())
                                     ));
                }
            }

    }

}


Products p = new PRoducts()
p.SelectAll();

now I have all my products which is nice.

this is okay, but i've been using it for a couple of years. I've heard about LINQ and Entity Framework but not really taken the step also played with nHibernate but not really taken to any. Is wrong to still be using this method.

Nothing wrong with sticking with what you know, so long as it works.

I would, however, suggest learning about the ORMs you mention and understand what they try to accomplish.

What you should never do is stop learning. Look at new frameworks and methods of development - if nothing else, it will make you a better programmer.

There is nothing wrong with using EntLib DAAB for your data access layer, especially if you only have a few classes / tables.

However, there are some significant benefits of using an ORM such as Linq2SQL, EF 4 and the latest version of NH:

• Auto Generation of Data Accessor and Entity Code
• Lazy Loading
• Support for LINQ Expression trees - this allows tremendous flexibility of query without any SQL coding (although the caveat is less visibility into the SQL being executed - this can have performance implications)

In most instances you can do about 90% of your DAL using one of the above ORMs, and for fine level 'control', you can hand build SPROCs. In most instances you can still wire your SPROCs to the ORM entities.

No it's not wrong to continue using what works for you.

Enterprise Library is still under active development and probably will continue to be used for quite some time. We use it extensively and will continue to do so for the foreseeable future.

I do recommend keeping abreast of the various things like Entity Framework for no other reason than understanding what the various options out there can do for you.

It's definitely not wrong to do data access in this way. It gives you the most control over the statements that get executed and how the data flows through your code.

OR-Mappers like EF or Hibernate give you more comfort in some scenarios, but they have their drawbacks also.

It is not "wrong," per se, but using this approach vs an object-relational mapper (ORM) like EF or NH is:

1. a highly imperative style (as opposed to declarative -- you are concerned with "how" more than "what")
2. more difficult to read
3. more difficult to maintain both because it is more difficult to read and because a change in the database can cause a cascade of changes throughout your data access code base
4. more difficult to test

I wouldn't suggest reworking an entire, working code base to work in an ORM, but it is worth learning and understanding. I suggest looking first at LINQ-to-SQL, in a sample project on the side, of course, as this is sort of the lightweight, "kid brother" ORM, but is very fast to start using. From there, you can move on to EF and/or NH. Entity Framework is more similar to L2S in feel and tooling, whereas NHibernate has a steeper learning curve but is more powerful/flexible.

Again, there is nothing wrong with using Enterprise Library and datareaders, but there are real advantages and usually time savings to using ORMs, most notably that the "dirty work" of data access is taken care of, and almost guaranteed to have fewer defects and to be more efficient than hand-rolled data access.

That said, for very small projects with limited use of a database, all the added abstractions may not be necessary, and straight ADO .NET will be faster and easier.