RE: Doc to DB

Jimmy looks intrigued by a conversation Mats and I had and asks some questions. He already asked me to write something about it and I did not, but answering questions is much easier than writing a white paper on this, so this time I’ll do what he asks ;).

As a background, the idea is that if we could find an easy way to build applications that work well with SOA then we could apply that solution for building any kind of application, while keeping some of the SO advantages in not SO applications.

The idea is to work with services but instead of using a domain model in the middle, map the message to the database, while making sure that the business logic is executed in the right places.

Now I’ll address Jimmy’s questions:

> The borders of the docs will be static, right? Could that become a problem for flexibility?

Yes, they will be static. It can be a problem for flexibility if changing the doc structure is difficult. If not, when you need a new field in the doc you just add it. Note than in SO there’s no good way to have ‘dynamic docs’, so we need to make sure it’s easy to change the doc structure.

> Do you envision overlapping docs or not?

Yes. The idea is that ‘Customer’ has a different set of fields depending on the context, so they overlap. For example, in the Order service the customer has Id/Name but in the Customer service it has all the customer fields. This is, IMHO, one of the main problems that OO has when working with SO. In OO a Customer is the same thing everywhere. In SO, it’s not.

> Would you recommend the solution for in-proc situations too?

Yes, if not, we are just adding another mapping layer, and that’s why we try to avoid.

> Do you see any drawbacks with behavior-less classes?

If we manage to find generic ways to solve all the behavior problems, then this problem does not exist. As we probably won’t (there will always be border cases that we won’t be able to handle), we’ll need to organize well the code around the ‘docs’.

> Will there be many places to change if there is a change in the database? Or do you envision some central model which will be the only place to change? If so, how do you envision the implementation of that model?

You can do a doc-to-db mapper, and that’s one of the parts of the problem that we already solved with DeKlarit.

> There won't be anything like an Identity Map or a Unit of Work across several docs, right?

No

> How is this better than DataSets? How is it worse?

It has no relation with it ;). You can do this with or without DataSets. If you are asking how different is this from using the DataSets in the ‘VS.NET’ way, then I’ll say that is very different, because the doc structure does not map to database tables, so your DataSets don’t break when your db schema changes.  That’s the ‘why is better’. I don’t see how it’s worse. Also, we are not talking about using IDbDataAdapters, but having a generator or a runtime mapper that knows how to load the dataset from the database, with a mapping defined with metadata somewhere.

> If the client's platform is unknown, what to give the client then? Validation stuff anyway? If so, in what format?

Let’s say we manage to express validations in metadata and we can know which validations to apply for each document. We can build generators/interpreters for that metadata in any platform (javascript, t-sql, c#/java, etc). The format can be a custom language, xml, a javascript subset, etc.

> How do we ask for a certain doc? By an enum (or similar) parameter? Or many fine grained services so the client can aggregate the doc by itself? Or only a few coarse grained services?

Only a few coarse grained services, like OrderAdapter.GetOrder(OrderRequest request)/ OrderAdapter.UpdateOrder(Order). 

>Regarding global rules (rules that require more than a single doc), will they go to the database? Or to a global doc? Or to what?

Global rules are rules that can be applied to more than one single doc (they don’t ‘require more than a single doc’). You express them in metadata. In DeKlarit it would be something like:

error(NotEnoughInventoryException, “Not enough inventory”) if Item.Inventory < 0

Then the framework should be able to know in which documents it should apply this rule (all the documents which could cause the Item.Inventory to be decreased), and generate code in those ‘document adapters’, or it could generate a trigger in the database. It could also generate code in the presentation layer for the rules that don’t require reading the database to be evaluated. We don't do this in DeKlarit (yet ;).

> Would you agree if I say that a doc sounds similar to what Martin Fowler talks about in the Presentation Model pattern?

I’m not sure ;), Fowler does not focus much in the document there, but I can certainly see how having this document would make applying that pattern easy. In addition to playing well with SOA, the documents play well with UIs.