There are many options map BO onto database schemas the main ones I have used, roughly in reverse order of time taken to complete:
- Hand roll converters that take the dataset/ reader and convert them to / from indivdual object types. Obviously the datareader is no good for updates.
- Write your own mapping framework. How you go about this is a little involved and a topic in istelf, but you can decorate the class and persisted fields with attributes that define how to get the information in/out of the database and write DAL stuff to support it
- Use an existing ORM framework. .NET has the Entity Framework for .net 3.5 SP1, but I'd only suggest it seriously for .net 4.0 + as the first EF version was poor. You also may find perfomance issues with EF (though you can do things about this) and it requires a well normalised database, if you are starting with database first. Another thing that might fit the bill in LINQ to SQL, it is supported (many people think it is isn't: they are not developing new features for it, though it has a pretty complete features set). Finally there is nHibernate, which I haven't used for years, but when I did you had to know your stuff to get the mapping right.
Options 2&3 will be
slower than option i you have a small OM with low complexity. Option 2 can get quite complicated, but is worth doing as an exercise as you get to see the challanges an ORM designer has to face. I wouldn't suggest it for a professional system unless you couldn't get what you need from a pre-existing ORM framework.
My suggestion is to give the Enity Framework a try: you can generate an object model from the database (assuming good normalisation) or generate the DB schema from the Object Model (with good normalisation, assuming a correct object model). If you have performance problems you can pre-compile queries and use stored procedures, so these can be worked around.