Is it better to create Model classes, or just stick with generic database utility class?

Question

We have a simple utility class in-house for our database calls (a light wrapper around ADO.Net), but I am thinking of creating classes for each database/object. Would it be smart to do so, or would it only benefit if we were using the full MVC framework for ASP.Net?

So we have this:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);

Thinking of doing this:

Person p = Person.get(id);
p.fname = "jon";
p.lname = "smith";
p.Save();

or for a new record -

Person p = new Person();
p.fname = "Jon";
p.lname = "Smith";
p.Save();
p.Delete();

Would this be smart, or would it be overkill. I can see the benefit for reuse, changing database, and maintenance/readability.

Answer 1

By no means is MVC the only design pattern for the web, but it is a useful one.

Adopting just the 'M' will pay dividends, in my opinion, even if you can't/won't adopt the 'V' or 'C'.

Answer 2

This question is loaded, data driven design vs domain driven design. For any application that has a good amount of behavior, then domain driven design should be preferred. Reporting, or utility applications tend to work better (or are quicker to developer) with data driven design.

What you're asking is "should my company make a fundamental shift in how we design our code". As a domain-freak, my gut reaction is to scream yes. However, by the simple nature of your question, I'm not sure you fully understand the scope of the change you are proposing. I think you should talk more to your team about it.

Get some literature, such as Evan's DDD book, or the free foundations ebook, and then you'll be in a better position to judge which direction you should go.

Answer 3

@Karl Seguin: Thanks for the info, I will look into those books. Sorry my question was loaded/simple. I didn't want to write too much, and probably should've just asked about Model vs. No-Model. The problem with my team is that I am new here, and they are running lots and lots of legacy very sphagetti Classic-ASP code, plus they still develop that way while using some of ASP.Net's features.

@Dan: Thanks for the input, I think I will start to add/replace the 'M' as you put it!

Answer 4

To me it looks like you are trying to do what LINQ can already do for you. If you are stuck in an older framework in which you cant use that, i might suggest that you use Subconic (http://subsonicproject.com/) instead of having to manually create all these model objects by hand.

I had a project where I was in a similar predicament and changed to subsonic halfway through with fantastic results. Quicker development and MUCH easier to read/use code.

Answer 5

The approach you discuss is considered a good one by many folk, me included! Learning this approach will require some effort, but don't let that put you off!

What about just trying a small project with LINQ to SQL? Perhaps find a nice reference project on google code, and study how others have worked with it.

It's a simple tool, and will let you become familiar with some of the issues that come up with mapping objects to databases.

You will then be able to get a feel for it, and decide if it's worth the learning curve.

There will be new concepts to grasp and experiment with, things like:

• Unit of Work: When you execute Save and Delete etc, an ORM tends to not do this immediately, whereas a recordset based DAL will. This can be surprising so you'll need to learn a bit about that. Read up on the Unit of Work pattern to get an understanding of this.
• Bulk Operations are an issue with OR/M. A data reader can efficiently iterate through thousands of rows, but with an ORM you have to be careful when working with large batches of objects. Again, one to read up on.
• Associations seem great when can do stuff like customer.Orders.Count but they are also the cause of many problems. You'll need to find some safe practices to follow when working with associations.

...to name a few.

For starters, don't worry about inheritance and stuff, just start simple and have simple entities that map to tables.

Try using them in the same way you'd use your existing DAL. Then start experimenting with associations.

Then perhaps try putting more behaviour in your entities. If you start liking this, and feel that you need more features, consider trying out a more feature-rich ORM like Lightspeed or NHibernate.

Hope this helps!