I was wrong about typed datasets. I see the light now, but i was wrong before.
The conclusion I came to was that Typed Datasets can be used in an enterprise application. The reason I thought this was a problem had to do with one missing link. An important link.
The Problem I had with datasets performing as business objects was that I thought that once you create a typed dataset, every layer that wants to use this dataset must have a direct reference to the assembly in which the DataSet resided in. I didn't know of another way one would go about doing this.
Addy Santo wrote in a comment to the last article ("TD's are not always the answer"):
"I'm currently working on a large enterprise app which is heavily based on typed-datasets. I used to be from the "typed-datasets-are-for-newbies-only" camp but I must admit that *when used correctly* they are an incredibly powerful tool. Several key things to keep in mind when architecturing around typed datasets:
1. Equating TDSes to the data layer is like limiting XSLT to the presentation layer - that is only one use among the many existing possibilities.
2. Since TDSes are based on XSD schemas, you can load any arbitrary XML block (which matches your schema) and programmatically work against it with a HIGHLY-PERFORMANT object model. XPath queries over the same XML aren't even in the same ballpark.
3. Since TDSes are typed, you get compile time validation, as compared to XML/XPath which is a pain to debug.
4. TDSes come with built-in serialization capabilities and funky webservice related optimizations. I don't have the bandwidth to describe my architecture in detail, but I am using datasets in several different capacities in my app and in every case they improved performance, reduced the amount of hand-written code and simplified the data structures. "
This comment contradicted my immediate sense of N-Tier design. How could one both use TD's in the scenarios Addy described and not break the abstraction layers?
I Started thinking on one of the things I'm working on right now. It involves loading a dataset dynamically from an XML file. In some debugging scnarios I made the Dataset (which is untyped) generate its XSD file for me, so that i could load it up in VS.NET and see the structure of the data as it is represented in the dataset.
I started thinking, "how can two different clients share the same typed dataset from a data source, of which they know nothing about, let alone have references to its DLL's?"
I guessed the XSD had something to do with this, since it is the way to pass around the schema of the data. I continued the out loud discussion with myself (with everyone in the room watching):
"OK. Suppose the Data source exposed the XSD schema to its clients. How would that help them? " The answer popped in right away: "A client should be able to generate a TD using the XSD schema as a blueprint.".
Typing out one small line in Google brought on This Link . voila.
To the rescue comes XSD.Exe which automatically generates Class code from an Xsd schema. The missing link was found. Now, all a client needs to do to be able to use typed datasets on data is to generate them from an XSD file the server exposes.
Simple and easy. Now you get all the power of TD's but without the handicap of references. TD's are not limited to Data Layers.
That's definitely good news (And I learned a lot!)