I hope I get to discuss all this with you guys face to face one day. I have a few good ideas that could be what we need between handgrown ORM and Strongly typed DataSets. And no I am not talking about ORMs - there's a better of doing it all.

ANyway, one day soon we'll talk.

The improvements to object binding in 2.0 are nice but where is the ORM tool?
I agree that building deep object models is a lot of work if you do it by hand. That's why Hibernate is popular in the Java world. There are tools to automate the building of deep object models even if one is working from an existing database.

.NET does still seem to be very much centered around the dataset. Where does Microsoft recommend we put our business logic?
It's confusing! The tools lead one to the dataset, and yet we are told the dataset is to be used only for simple logic. One might conclude that .NET is only suitable for simple applications or that it is an incomplete framework (i.e. no out-of-the-box support for ORM).

I’ve received a few questions, so I wanted to post a quick reply.

The issues Shawn is referring to is how much flexibility is realistic with the Typed DataSet generated code. I wouldn’t say that inherited typed datasets we’re really “born”, so it’s hard to say they’re on their death bed. Shawn had some very good “asks”, but it’s fairly complex to implement, test and support all these scenarios. We didn’t seal the classes, but this wasn’t really a target scenario. Anyone inheriting from Typed DataSet will agree this wasn’t an easy task. What Shawn, and others, are looking for is the ability to control all the generated code, and insert their own derived DataTables and DataRows. This is a common ask. Developers have asked for some sort of template to control the generated code. I hope that we’ll get an article out soon on how developers can write their own TypedDataSetGenerator and register it within VS. I’m sure articles exist, so I’d be happy to promote one if you can point me to one.

On the question of DataSets and Objects: Typed DataSets provide a great canned solution for most people and we will continue to build upon DataSets for a long time. DataSets maintains collections of rows, it keeps deleted rows, it tracks the rowstate, proposed and current values. It serializes across web services as XML or binary, it slices, it dices… You get the idea. We’ve done a lot of work in Whidbey with Partial Classes to continue to build upon Typed DataSets and extend their reach as far as we can. However, we shouldn’t force a one-size-fits-all solution on developers. This is why we now provide better design and runtime support for your own objects. It’s just a choice.

-Canned, easy to use solutions that provide a lot of the common needs
or
-Support for the roll-your-own, no limits object models.

I'm working on an article that describes how you can leverage Typed DataSets and TableAdapters to fill your objects, so “please stand by”...
Steve
http://blogs.msdn.com/vbteam/category/4754.aspx

I understand where steve is coming from, however as an avid proponent of typed datasets (it really works !!) I think that changing the generated code to be easily inheritable is good design and not a feature (unless you consider good design to be a feature :-). I have found that using the ADO power toys type dataset generator immensly helpful as a business object layer. It simplifies development and provides a good amount on encapsulation from the database if correctly used. The default code generated from typed datasets, as provided by microsoft does not do this. It would be sad to see the continuation of this handicap in any way. It is often noted that users of software end up using it in completely different ways than what the designers intended. It is not for the designers of a data layer abstaction framework to force their use cases on the users of the framework, as it then ceases to be a framework.

Just to be clear here, I'm not suggesting we’ll be doing anything to discourage inheriting from typed datasets. We certainly won’t seal them, or change anything to private. All I’m suggesting is we didn’t originally design typed datasets with this in mind. Changing the generated code isn’t a trivial task. Developers have come to depend on the code we generate, good or bad  I think it’s a great idea to provide alternative generators, however, the changes that Shawn and I discussed, while very intriguing and empowering have a cost for us to develop and more importantly a high cost of support. This is why I’m just suggesting the title of the blog is a little misleading. We’re not killing anything. We’re simply raising our son, the typed dataset, to be a basketball player, not a football player. It wasn’t designed with features required to support football, (inheritance), however, there’s nothing saying you can’t take the same gene pool and reshape it. Ok, this is getting a bit weird… By all means, create new generators. I’d really like to see this as a community project. I’m pretty sure we’ll be documenting the new XSD elements we’re using for TableAdapters.
Steve

Hi. I was just pointed to this blog by a guy I was having a discussion with about Typed DataSets. I just wanted to add my 2 cents that I don't why you guys say that inheriting from a Typed DataSet is difficult or a lot of work. We sub-class every one of our Typed DataSets and it's pretty much a no-brainer. Granted, we wrote a little tool to do it, but still, even that was a no-brainer.

~~Bonnie

I am not convinced : Help me here !

I know that you are not suggesting that people dont inherit from typed datasets, but with respect, I think you are dodging the issue:
There are two main requests here:
1.Have complete control over the way that the code is generated.
2.Change the way the existing code is generated so that by inheriting and overriding...., that the generator wont stomp on all the changed code...

I can understand the effort involved in 1. Working with code generation is not trivial, and to this I concede. I have a hard time with respect to comments related on the second issue .
Changing the signatures to facilitate easier inheriting will not adversly affect peoples dependency more than it will benefit them.
If this is a common ask, then surely you would concede that it is a valid use case, intended or not !.
It would benefit the microsoft development community by making this the default behavior. By being able to do this has nothing to do with the original intent of the dataset... at the end of the day it is an inheritable object, that is "not so inheritable" primarilty because of the way virtual overiding is used ;-(

By the way, what if you son wants to play basketball and football, and is its illegal to use gene therapy in professional sport. Does he now have to choose ? ;-)

One of the biggest problem our company faces while using typed DataSets is where to put the business logic. I didn't build the app, however, I need to support and now add new functionality. It is apparent that the builders didn't take a n-tier approach.

I have BL in the database, in the code-behind, sometimes in BL classes but mostly always in the code behind. Maintaining this app has already caused one of the newest team members to just walk out the door. Adding new functionality to this complex system is even a bigger challenge.

I have always developed .Net/C# applcations with an OO approach and want to use inheritance, design patterns, etc. (the good stuff). So with the possibility to inherit from a DataSet and provide proper abstraction in my BLL/DAL.

I like the ideas that Steve Lasker presented in his article outline - I am building the same model using a custom ORM approach...the problem I'm having is that I'm trying to duplicate the same functionality already present in typed DataSets. So, this looks like a viable solution. The power and functionality of DataSets and the control of OO design. I will also want to use a code-gen tool like MyGenerationSoftware.com to automate the creation of these classes.

<i>Been there, done that, bought the t-shirt</i>

I just posted another sample, or more of a blogicle (long blog that looks like an article) for how to combine objects and the Data Designer features. Basically this gives you a DAL with an object model on top of this for you to add all the business logic and functionality you'd like.
http://blogs.msdn.com/vbteam/archive/category/4754.aspx

Just my 2c.

Typed Datasets the generation could be done using a custom generator as others have pointed out.

The typed datasets are "dumb", meaning each table is individual object and has no real possiblity to validate across tables.

Eg: If User is base table and possible derived tables are Vendor, Customer, Partner, etc. Based on the UserType, corresponding child table is required, there is no way we can do this in Typed Dataset or i need to be enlightened.

Hence my rule of thumb is Table related validations, column values/domains, combinations, etc. could be validated, so that as user is typing in bound form, the XXXChanging events could trap and validate in typed dataset.
However the cross table validations is what BL should do.
This is the essence of what BL does period. BL should be bothered with simple DL/Table level issues.

Till Objectspaces becomes more mature, i think ORM will have to wait, due to lack of generators, complex/manual work to create hiearchial model. Imagine Word/Excel kind of ObjectModel equivalent for a Departmental business model.
Forget about Enterprise wide.

The beauty of typed dataset is, it can be compiled as a seperate .DLL and shared among the following layers we use:
- DAL
- BL
- common Validation [between UI and BL]
- Presentation layer.

It is still lightweight. How will ORM/Object Space allow that, since it is primarily aimed at BL.

Also will ORM support true "STATELESS" BusObjs?