Alan - for someone using Access as a back-end, a book on enterprise design patterns is complete overkill imo - the use of DataSets in this scenario is perfectly adequate. Indeed, I've worked on some pretty large projects where DataSets have been ideal - yes, they are heavier than a POCO but in a lot of cases that doesn't matter.
Moving to a POCO based approach brings with it a whole lot of pain - you need to map your database to the POCOs using either a custom mapper or an existing framework (ActiveRecord, NHibernate, EF4.0 etc) - none of these I would suggest are suitable for the OP. In this case I would suggest moving away from Access if possible (SQL Express is far superior, and is free), implementing your database logic as Stored Procedures (this would echo the query based approach used by Access) and continuing to use DatsSets. If, at some point in the future, you outgrow DataSets, then by all means look at Alan's suggestions. Furthermore, I would echo his suggestion re: improving your Database skills - I don't like hearing people say "Since i am not a good databse designer"! On Thu, Jan 14, 2010 at 5:51 PM, Anachronistic <[email protected]> wrote: > Mr. B, > > Have you considered writing custom objects to wrap your tables as > opposed to using strongly-typed DataSets? While convenient, they're > heavy, and they do have particular requirements and limitations. > Custom objects can be as large or small as your requirements dictate, > and although you'll need to make updates to the objects as you change > the schema and so on, it's far less painful than DataSets if done > properly. > > I would recommend you look at any of Dino Esposito's books, in > particular "Microsoft .NET: Architecting Applications for the > Enterprise (PRO-Developer)" which is available from Amazon for about > 30 bucks. He discusses a lot of design patterns in that book for > handling custom object-based data layers, data transfer objects, and > so on. The focus I believe is primarily SQL Server, but Access in this > case can easily be treated as fairly identical for the purposes of > your work. > > Beyond that, I would also suggest reading up on the topic of database > design. "Beginning Database Design" by Churcher (~$30 on Amazon) is a > well-reviewed book that would likely make a good starting point. If > you adequately design your database at the beginning, the application > will run better, your maintenance tasks will be reduced (if not > altogether eliminated) and you won't have so many of these development > headaches. > > Hope that helps! > > Alan > > http://www.twitter.com/anachronistic >
