March 2004 - Posts
Richard hosts speaker training sessions in Microsoft events.
I had a session with him last year for TechEd. I had another one today, preparing my tomorrow presentation.
I told him that the last time all I got from him was 'slow and loud', and that I wanted something else ;), and he gave me that. He even made me change my powerpoints. But it was fun and I learned a lot. Let's see if I can make good use of it tomorrow.
After the session was finished, there were some guys in the speaker lounge looking at the posters in Despair, Inc. I've seem them all, but every time I look at them I get a good laugh, so even if you heard about them, click in the link and have fun.
After the PDC I said that Avalon is a luxury item. Scoble said that I was wrong. But it seems that he changed his mind.
;)
At last, someone from Microsoft who is brave enough to suggest that putting the business logic in the database may be a good option in some scenarios.
The idea that all the work MS is putting in Yukon/CLR integration is just to write UDTs and UDFs, or 'things that cannot be written in T-SQL', like encyrption, does not make a lot of sense.
Frans also blogs about Optimistic Concurrency.
In a perfect world we would like to find ways to not to have concurrency problems, but I don't live in that world.
We need to deal with them, and we need to deal with optimistic concurrency errors.
Caching is a good example on why we need optimistic concurrency. If you have data cached, you cannot have any lock on it (you cannot have even a 'Pessimist Offline Lock'). When you read that data and update it, you'll need to apply optimistic concurrency. If you don't support optimistic concurrency you cannot cache.
On the other hands, your users don't like these kind of errors, so you need to avoid them. That's why you need to be able to check only for changes in some fields, and why a 'version' column is not always a good idea.
If you have columns with a lot of concurrent updates (for example, a product's inventory) then you'll probably need to have some rule to not to trigger the error when the values are different, of course making sure you apply the right operation to the column (for example, if the product inventory changed, unless there is not enough inventory for the operation I'm persisting, I don't need to raise a concurrency exception).
Frans got to the conclusion that we don't need O/R mappers in a SOA world. He argues that a 'Manager' model that provides services to data would be a better choice.
Of course, I agree with him.
When we talk about a domain model we talk about having objects with behavior. You could think that a Manager model just means to take the behavior out of the objects and put it in the manager, but keeping the same object model.
If you do that, then you still won't be able to survive in a SOA world. You cannot use your classes to automatically define your messages, because the structure of the messages may or may not be the same as the one in your classes. You may need to include some fields from different classes but not all of them. You don't want to send a Customer with all its related objects (i.e., a Customer with his Orders).
So, you still need to have a 'mapper' that creates the messages based on the object model.
The other approach is to not to have the object model at all, and map the messages (which have fields from multiple classes or tables) directly to the database. IMHO this is a better approach in most of the cases.
The problem with the behavior-less object model or with mapping directly the messages to the database is what to do with the business logic. Writing the business logic in each 'Manager' will probably lead to redundant code, as you may have to deal with three 'Order' Managers, with a slightly different structure, and you'll need to have three Managers.
I think the answer to that is business rules. We could have a rule that says 'the order date should be greater than today' and have it automatically applied in each Manager that deals with Orders.
Biztalk 2004 has a business rule engine that I still was not able to try, but it may be a step in the right direction.
I'll be attending to the MDC in March, and I'll be doing a presentation on the new DeKlarit features for the Compact Framework and SQL Server CE. Below is the abstract:
CLI361 - Accelerated development of SQL CE and .NET Compact Framework-based applications
In this presentation you will learn how you can use DeKlarit 3.0 to easily design, create and maintain your SQL CE database schema, data access and business logic layers. In addition, you will experience how DeKlarit greatly speeds up the development of your Pocket PC presentation layer, taking advantage of its deep integration with Visual Studio .NET.
See you there!
Updates in distributed application usually involve performing optimistic locking on the data to be updated. This requires to store a copy of the previous column values or to have a 'version' field in the database table to compare against it.
Let's say we decide for the first approach.
If we have a stateless middle tier, then the old values and the new values needs to be sent to the middle tier in each update, so it can compare the values and perform the update. If we have a stateful one, the values could be kept in the middle-tier state. A stateful middle tier is as its own set of problems, so let's say we decide for a stateless one.
If we need to send the old values and the new ones, the data structure that is exchanged through the tiers should support storing the two versions of the data and sending the differences.
DataSets do this using diffgrams.
I have two questions:
- How do you deal with this problem if you are not using DataSets to exchange data between tiers?
- How do you deal with this problem if you are building a Web Service that needs to talk to Java, that does not have built-in support for diffgrams?
More Posts