Should a .Net beginner bother with ORM or wait until he gets more experience?

I am relatively new to .Net and the database side of it in particular.

I'm planning to rewrite some legacy V开发者_运维问答B6 applications here using .Net and C# with Visual Studio 2008.

I've studied things like strongly typed datasets, Table Adapters, etc. It works quite well but I find strongly typed datasets to not be perfectly manageable, especially when database schemas change and the code feels way more procedural than object-oriented. I find that it tends to clutter the code a lot as well and the generated type names tend to be very long...

Considering that I'm relatively inexperienced with .Net, I do not really want to increase my learning curve even more, since after all, I have deadlines... I've looked at things like NHibernate and it looks intimidating... I'm not sure to have the time to understand how their XML files, etc, work at the moment...

In short, should I bother with ORM at the moment or wait that I have built more experience with .Net, and ADO.net... even if it means having to rewrite the application to use ORM in a few months when I'll be settled.

I realize it is a subjective question, but I'm sure the answer of experienced developers who traveled both roads or had to train new recruits would be useful to me.

Thanks in advance,

You can try BLToolkit: it's, among other things, a pretty simple ORM:

public abstract class PersonAccessor : DataAccessor
{
    [SqlText(@"SELECT * FROM Person WHERE FirstName = @firstName")]
    public abstract List<Person> GetPersonListByFirstName(string @firstName);

    [SprocName("sp_GetPersonListByLastName")]
    public abstract List<Person> GetPersonListByLastName(string @lastName);
}

I would highly recommend looking into Mindscape's LIGHTSPEED. Excellent platform and built on really good disign principals, really cuts down on development time once you get a hang of the basics. Also do a feature comparison to nhibernate, entity framework etc.

It sounds like you have a number of (I would guess relatively small) apps to rewrite, so I'd be tempted not to use an ORM right off the bat. For your first app, just try writing the data access code yourself using ADO - but try and make sure everything is well-separated, for example by using the Repository pattern. This way, if you decide to, you could swap out your ADO DAL for something using an ORM fairly easily.

Once you've done it yourself, you'll have a better understanding of what an ORM can do for you and whether you want to use one or not (which you probably will!).

Also, and this really depends what type of app you're writing, but I'd suggest sorting the Model out first (the core classes of your app, commonly 'Employee', 'Order' and so on), and then make your data access based on that. Doing it this way, you could use something like EF4, NHibernate and so on, which can generate the database schema based on your .Net model classes. (Although it would mean you can't use Linq to SQL as easily, as that requires having the database in place first).

If you did want to use an ORM, and you're using SQL Server, Linq to SQL is easy to get going with. The main downsides are you can't do model-first development, it only supports SQL Server, and it's no longer in active development so might no be a good thing to spend learning time on.

You are going to have to learn some data access method, so you may as well use/learn an ORM.

I would go with Microsofts Entity Framework.

Have a look at WCF Data Services: http://msdn.microsoft.com/en-us/data/bb931106.aspx