Benefits and drawbacks of strongly typed datasets for DAL in .Net

Question

I'm currently working with a system that has inherited a DAL using .Net's strongly typed datasets. I have never worked with them before this, but I'm finding that I have a strong aversion to using them. Compared to a POCO based DAL, them seem to be clunky, difficult to manage, and the resulting objects are highly coupled with database-specific concerns (eg, accessing objects from tables and rows, getting desired data by key values, etc -- isn't the entire purpose of a DAL to abstract this away from logic layers?).

There has been some discussion about rewriting and/or re-factoring parts of the database layer. I, personally, would like to see these datasets removed, but I'm having a hard time convincing some of my colleagues, who are used to using them.

What are some of the pros and cons of using strongly typed datasets vs. a POCO based DAL? Am I justified in my aversion to strongly typed datasets, or is the community consensus that they arn't a problem? Are there any other solutions that I'm missing?

Although I also agree that there are benefits to using an ORM framework like NHibernate, I think a library of that complexity would be a hard sell on my colleagues. If anyone can provide a compelling enough argument to this direction, I would like to hear it.

Answer 1

Strongly typed datasets were an easy way to do a designer-based approach to database access. They could be generated from the database and are fairly easy to update. They also have the benefit of enforcing data types.

You can think of them as a transitionary stage between raw ADO.NET with DataSets, DataTables, and DataAdapters, and Entity Framework. I would try presenting Entity Framework using the designer and database first code generation as a replacement for the current method to your colleagues. It should be a familiar pattern and will allow them to transition more easily. It should also be the lowest amount of additional work to retrofit the existing code.

You can use that introduction to work on their comfort level and later on start to introduce POCO, Linq and separation of concerns in new projects. Remember that, typically, the faster the pace of change (and/or the higher workloads are), the greater the resistance. If you can present new methodologies in bite-sized pieces and as safe-feeling proof of concepts, you'll be much better received. Change is risk, so management of both perceptions and potential work expansion due to unknowns is important.