Revisit dataset – let’s use both dataset and custom class without custom collections

Revisit dataset – let’s use both dataset and custom class without custom collections

[update: see my later blogs for updates. In short, dataset is bad; this blog only reflected the enthusiasm when I started to use a new feature from M$. This is just yet another example why we need to test technologies out in a small project, especially when those technologies are from M$ -- the reason? Because of the nature of being the monopoly vendor, M$ tends to release technologies without community discussion; instead, it tends to “create” some technologies in secret, and simply push the technologies by marketing – more problematically, in the past, when it created the technologies in secret, M$’s focus was always the “mort” market – that makes the technologies from M$ often problematic for serious enterprise computing. Again, strongly typed dataset is just another example. It is good that I blogged it here; now we have a real example why sometimes I am suspicious of the marketing hypes; however, that suspicion does not prevent us from trying. Again, always try new technologies in small projects; always be hand-on].


I read the Rocky’s post:

http://www.lhotka.net/weblog/CommentView,guid,ad5be814-6063-43e0-b703-932771444b98.aspx

It has been in my mind ever since.

If validation (and property level authorization) can be done cleanly, then, as long as at method level (no need to be at class or dll level – come on, CSLA’s business objects are also a mix of entities and façades) UI and business logic are cleanly separated, then, what the hack, let’s use datasets.

Dataset (especially typed dataset) is "simple-minded" OR mapping. I know it is called as “table module http://www.martinfowler.com/eaaCatalog/tableModule.html , but I do not want to use that name here. To me, if it is in-memory, it is “object” by definition; so, anything helps to access relational database from in-memory is OR mapping, by definition. The difference is whether it is a simple one, or a complex one.

------------------
I guess this is the problem of pattern writing. When you write a pattern, you emphasize the difference: what is the special thing about dataset. In order to do that, you give it a name, implying that its is stable, and has some “essence”.

This is harmful when the “thing” is in flux. The real “essence” of dataset is OR mapping as simple as possible.

By putting dataset in such a perspective, we emphasize we can use dataset with custom class. Also, we are implying that it is worth it to grow with M$, especially from now on, to study it in each version.

Then, you may ask, how about the DLING, the real OR mapping. The problem is the “real”. How about Nhibernate. You believe DLING will eliminate NHibernate? I doubt it. They are all OR mappings, with different kind of trade-offs.

This point is extremely important for my own “enlightenment”: when you use a concept like “table module”, be careful; when you study “patterns”, be careful.

I want to repeat this: in VS 2005 typed dataset is a simple but mature OR mapping technology; it is simpler, but not that different from DLING and Nhibernate. The investment in typed dataset can be transferred to future OR mapping technologies.

This is important, because the major reason of ignoring typed dataset is the reversed FUD: we do not know the future of dataset; it changes for each version; so, let’s ignore it.

Because of the huge amount of half-cooked technologies from M$ in the past, such attitude has its merits. The problem of it is that by it alone we do not know when to change that attitude. We have to keep an open mind, and continuously “poll”, “peek”, and “test-drive” those half-cooked stuff, to see whether they are ready to be treated seriously.

I am reporting now (I know I should do at least one year ago) that, dataset 2005 should be treated seriously: as a whole, it is not a half-cooked technology any more; you can seriously use it in enterprise computing, because it is a simple but mature OR mapping technology.

Again, it is incorrect to say that dataset is inherently different from “domain model” and therefore inherently differently from OR mapping technologies.

------------------

It is full of compromises; however, it seems that the 2005 version strikes many good compromises.

In short, I will begin to use dataset “positively”, i.e., not just for some hacks, or maintaining “other people’s code”.

Again, I will apply rules I use in “pure” object world: parsing-and-validation (and property level security) and formatting are “business rules”, and must be in “business layer”.

---- more:

I believe anything in memory is an object (this is indeed a fact, instead of a belief).

I also strongly believe in the so-called “anemic domain model”. Looking back, it is so obvious that “anemic domain model” is close to the “simple-minded domain model” – dataset.

In an application, for most parts, we can use dataset; we use custom entity class when it is mostly in-memory (ya, you can create “shorthanded” dataset, but why). Also, as a absolute rule: when we need to use data binding in updatable grid, then we must avoid using custom entity class -- by doing this, we can avoid all the complexity of custom entity class approach (e.g., those collections to support data binding).

By the way, CSLA is the best for custom classes in .net world. Howver, it has two things I always feel of great pain: portal's limitations and strongly typed collections. We can take away portal easily (and the limitations it creates); and we can use dataset to avoid collections. What is left? – Again, the concept that validation/formatting is business logic; not UI logic – yes, this rule is very precious. And its practical meaning is that I can unit test it easily.

OK, that’s all for my convert manifesto ;-)