September 2005 - Posts
Recently Dennis asked me (here) to set up a location in space to ventilate our thoughts on modern software development. A service to collect thoughts… to be continued.
It made me smile to hear a national respected developer talking almost heavenly about agile software development and claiming afterwards that OMG’s MDA overrules Microsoft’s DSL initiative. His argument: what if you want to switch platform in lets say, 5 years.
ps: lack of inspiration bogged down my writing frequency, sorry for that.
I spend the evening catching up on the latest PDC/blog news and finished reading the largest part of the Linq/DLinq documentation. I couldn’t resist on quoting the following piece of text:
The best solutions so far have been elaborate database abstraction layers that ferry the information between the application’s domain specific object models and the tabular representation of the database, reshaping and reformatting the data each way. Yet by obscuring the true data source these solutions end up throwing away the most compelling feature of relational databases; the ability for the data to be queried.
Notice is the “domain specific objects models” part. Interestingly enough, I found it in Microsoft documentation :D
O, and Frans is right about the attribute based programming model on top of DLynq. Hopefully Microsoft will acknowledge this fact and provide a solution in the area of tooling support.
I prefer DLync over ObjectSpaces, wise choice.
Today we discussed "The database should keep his mouth shut" some more. Stefan (team member) mentioned how to cope with bulk data loads on that same database since for such a scenario triggers, constraints etc seem obvious. For now I haven’t given this idea as much thought it deserves. For the time being I think that if a bulk data load feature is important to your application, then why not embrace it in your model as a supporting role? Identifying a bulk data load as a supporting capability eventually leads to a Segregated Core. Thoughts?
In a discussion what responsibilities a database should carry Max (our team lead) responded "The database should keep his mouth shut". Which is, if you think of it a pretty interesting radical thought. What he ment to say was that the database is subordinate to the model and it’s only goal is to store some data. All inconsistency and integrity checks are a responsibility of the model. A radical thought which clearly explains the philosophy behind DomainDrivenDesign.
A while back I wrote a few lines on Service Anti-Patterns, Command vs. Document Message. Today Rich Tuner outlines “RPC” vs. Messaging in WCF. Sure I’m influenced by Dare Obasanjo (since I read his “On Moving On From Microsoft in 5 Years” a couple of minutes ago) that Microsoft's decisions are primarily based on protecting market share. Was this the deal with offering both programming models in WCF masqueraded under the term flexibility? Why did the Tech Ed CTS track (it was still good old Indigo back then) gospel only talk about explicit messages?
If I can’t make up my mind this only means I’m flexible either way? Interesting…