.NET Object persistence options

MrEdmundo picture MrEdmundo · Mar 4, 2010 · Viewed 7.9k times · Source

I have a question that I just don't feel like I've found a satisfactory answer for, either that or I've not been looking in the right place.

Our system was originally built using .NET 1.1 (however the projects all now support 3.5) and all entities are persisted to the database using stored procedures and a "SQLHelper" that has the standard ExecuteReader, ExecutreNonQuery type methods.

So what generally happens is we'll have our entities for example, User and Role and we'll have another class called UserIO that persists those objects to database with methods like:

 static UserIO.SaveUser(User user)

The reason for the separate IO file is to keep the IO separate from the entity however isn't it more satisfactory to just to call?:

User.Save()

Maybe I'm wrong but it just doesn't feel right to have these "IO" files scattered all over the place. So I'm thinking about looking at other options for persistence and I wondered where would be best place to start. I have used datasets in the past but had some mixed experiences particularly with their performance. I know LINQ is around now but I heard that rather than LINQ I should be using the ADO.NET Entity Framework but then somebody else told me the Entity Framework isn't quite right and I should be waiting for C# 4.0. If that's the case and with C# 4.0 just around the corner should I just carry on with my "IO" file approach and start with the Entity Framework when C# 4.0 is finally released. Or is there perhaps a more elegant class structure I could using e.g. utilizing Partial Classes?

I should say, I'm not looking at completely replacing the data access that already exists, I'm more concerned with the new entities I'm creating.

I'm sorry if this question is a little general, however I don't have many people around to bounce this kind of thought off.

Answer

John Saunders picture John Saunders · Mar 4, 2010

I have successfully used Entity Framework 3.5. There are some, who I would characterize as purists, who felt that Entity Framework violated some set of rules, and should not be used.

In my opinion, the only rules that matter are your own. I recommend you begin experimenting with Entity Framework 3.5, since you have it now. Also, as soon as you can, you (and just about everyone else) need to begin experimenting with .NET 4.0. The Release Candidate is available for free, so there's no reason to not at least know what's available.

It's possible that you'll find you like the EF changes in 4.0 so much that you'll want to wait for it. It's just as likely that you won't feel a need to wait, and can go ahead and benefit from EF as it is in 3.5. I have, and I'm very glad I didn't wait.