October 2004 - Posts
The VS.NET Enterprise Tools team previewed the DSL support in VS.NET in OOPSLA.
I just found Harry Pierson has a post with all the links I was going to post, so I'll point to him ;)
It also seems they plan to release a DSL Tools addin for Vs.NET soon.
Here there is a screen shot that looks like a designer for the UIPAB
I'm really excited about all the DSL/Software Factories stuff. We don't need more non-executable models, and finally there's a BigCo that goes for it.
I'm reading 'Sofware Factories', the book where the VS.NET Enterprise Tools guys explain how they think the software development process can be improved dramatically.
It's a 600 page book, with solid theoric background on patterns and modeling (it's not a patterns book, it refers to the roles they play in an application).
The 30 second elevator pitch is that we cannot continue to develop software as craftsmen and we need a more industrial approach to it. They believe that a mix of modeling tools, frameworks, patterns and code generation can make that a reality, and I fully agree.
I think it will be an important book to help changing the mind of the developers who think they need to manually code each line of their applications.
I read from page 1-140 during a (long) flight, and as I wanted to get to the meat of it, I skipped 300 pages, to the part where they explain how they think the application code will be generated.
Their basic code-generation construct is a rule like:
IF
(WS_DSL: ?wsl is a web service) and
(WS_DSL: ?wsl offers port ?p1) and
(WS_DSL: ?p1 request message ?m1) and
....
THEN
.. Generate code somehow (using a template for the code snippet, use a CodeDom or just use WriteLine)
The 'IF' part queries the metadata model, and the 'THEN' part generates the code.
As we generate code in Prolog, this made perfect sense to me. It looks exactly as the kind of code we use in our code generation engine. In fact, they take Prolog as a valid implementation language for code generators saying that the main drawback is that the metadata needs to be written in Prolog (which is not a problem if you don't write it manually, even if Prolog is simpler to write than XML for metadata ;).
The other approach that seems valid to them is to evaluate the 'IF' part using a query language like XQuery/XPath or SQL. That makes things easier, but you will still need to evaluate all the IFs for every rule and you won't have backtracking so I still think Prolog is much better.
One problem that I see with their approach of using one Domain Specific Language for each domain, is that the metadata from one domain is not isolated from metadata for the rest of the domains. For example, if you have a DSL for defining Business Components and you have a DSL for defining web services, then you'll probably use the metadata in the first model as an input in the second one, and you'll need to have them synchronized (i.e., if I rename a Business Component I need to rename the entry in the web services diagram).
They probably can address this with 'model to model' synchronization, or by having a way to centralize metadata, like having a reference to the Business Component DSL in the Webservices DSL. Anyway, if this is stored in XML files then it can be hard to manage (e.g., no referential integrity), so it's probably better to use a database for this, but then everything looks more complex.
Perhaps this was discussed in one of the 300 pages I skipped. If that's the case, I'll found out later this week and let you know ;)
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.
Jimmy Nilson says
"I see Lazy Load as being something technical, and it is not important for the Domain Model itself."
I see Lazy/Eager Load as something very important to the domain problem. When you lazy load you can load data that is not consistent. If you lazy load an Order, first the header, then the lines, and someone adds a line in the meantime, your Order.Total won't be the sum of the lines. That can lead to important issues in your application. Matt Warren blogged about it sometime ago.
That's why DDD defined Aggregates, and IMHO that's the more interesting concept that the book introduces in the 'Domain Model' paradigm. An aggregate is a unit that needs to have internal consistency and needs to be saved and loaded at the same time. If you follow DDD then you should load aggregates eagerly, and that's a domain model level issue.
There's a very interesting article in the MSDN Architecture Center that's very close to my heart ;).
If you think you can have a service methods called Add/UpdateOrderLine(fields of the order line table), read it.
If you think you can have the same methods in your business logic layer, read it.
More Posts