Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Churchill, Google, optimistic concurrency and the PAG team

Today I demoed DeKlarit to part of the PAG team in Redmond.

In my presentation I was going to address the issue of dealing with concurrency issues in distributed applications.

I wanted to say that optimistic concurrency is the best generic solution we have, but it is not a good one. I remembered a Churchill's quote about democracy that could apply to that case. I googled for 'Churchill democracy' and found the quote as the first result. My powerpoint end up saying that "Optimistic concurrency is the worst way to handle concurrency except for all those others that have been tried."

Thinking that google it's still cheap at $150 I continued preparing my powerpoints, and I wanted to include a reference to a recent MSDN article that touched this issue. I googled for 'crud when you can afford it'. My post about the article was the first hit. The second was the real article. I was happy with google for a second time in the day, but this time I was not very sure of the quality of the search result ;).

BTW, my main point in the presentation was to tell them what we think that a messages + declarative business rules layer on top of the database are (usually) a better approach for building applications than a service layer + domain model. I think they got the idea.

 

5 Comments

  • Hi Andres,



    Could you elaborate a bit more why you think "messages + declarative business rules layer on top of the database are (usually) a better approach for building applications than a service layer + domain model"?



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

  • Hi Jimmy,



    Imagine you have a message with the data for each different use case.



    You have a DTO with the data for one kind of user interaction, or for each integration scenario.



    You receive the data, apply business logic and store it.



    What's the problem with this approach? If you have ten different use cases that, for example, update an Item Inventory, then you could need to write that logic 10 times, and write validation code that checks if you have enough inventory 10 times. That's why you want to have a domain model. You place that logic in only one place.



    What if the mapping between the message and the database can be automatically done? Think in a message-to-relational mapper. Then you won't need to write the code to persist it, but you'll still need to check if there is enough inventory.



    What if you have an automatic way to know which rules should be applied in for this use case? You could say declaratively that if the Item inventory < 0 after processing a message you should throw an exception, have a way to identify which messages update the inventory, and apply that rule. This rule could also be smart enough to know how to retrieve the Item Inventory in the current context.



    Once you have this infrastructure built (message/relational mapping and rules engine) then you can build most kinds of applications much more easily than using a domain model.

    For some (probably most) applications, you could also want to add a workflow engine to the mix.



    If I wanted to reach to an agreement soon with the people who love domain models, I'd say that at least it raises the bar for where an application's complexity requires a domain model ;).



    I'll say that if this turns into yet another religious discussion about the subject ;).



    Regards,



    Andres

  • Interesting! I remember such a discussion at the ObjectSpaces newsgroup a year ago or something like that. Have you published anything about this yet?



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

  • For now, all my writing about this is in C# and Prolog ;)



  • OK, but that will change soon, right? I'm looking forward to read some about it!!!



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

Comments have been disabled for this content.