What do you think about using Typed Datasets for the business entities?

Couldn’t they be de-coupled from the data schema? (The property names do not have to match the database column names).

DataSets are just data, you can map that to tables/columns or to whatever you want.

Objects look great, but most of the not-scalable solutions I’ve seen in the past years were not because they used the equivalent to dataset/datareaders. They did not scale because they tried to use objects using a pure OO design with a relational database in a distributed design. This is the evil, and that’s why object/relational mappers are really the most dangerous things for scalability.

Personally, I’m for less work – getting Rapid Economic Justification for what I’m doing early – whatever that means. I don’t think that Datasets are always the right thing to do – I also don’t think that datasets are NEVER the correct solution. On a previous project, the typed dataset was a friend – we built a pure metadata driven system and hence had no “business objects” because it all needed to be completely dynamic. It was impossible to perform object-relational mapping – and thus this type of design pattern worked. In fact, our objects were PURELY declarative at run time! (and yes, performance and scalability were the aspects we let slide) For each project you need to look at all of the various associated risks. Is it performance, is it scalability, is it security, is it change, time, money, resources? (and there are more) All these together help focus the architecture decisions you make – one design pattern does NOT fit all.

But I do have to say, I agree with the points around existing samples (or lack there of). I think I would like to see much better samples around design patterns – along with guidelines on how to select the correct design patterns for different situations. A map for non-arhictects perhaps – and then for each one a SOLID example.

I was just speaking in generalities about the use of DataSets and DataReaders and yes its very scary what I see out there. Almost all .NET developers have virtually zero knowledge of how to properly design scalable transactional systems. On the otherhand I have been doing this since the 80’s. Cheers.

http://www.microsoft.com/downloads/details.aspx?FamilyId=E2930625-3C7A-49DC-8655-A8205813D6DB&displaylang=en

check out the code!

I look forward to the rest of your arguments.