Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Separating business logic from technology: Kathleen Dollard on a new view of code generation
Posted by Sadek Drobi on Dec 21, 2007 10:11 AM
Separating business logic from user interface code was one of important lessons that legacy Visual Basic programs taught us. Kathleen Dollard actually argues that business logic should be separated from any technology to avoid rewriting everything when a new technology comes up. And, according to Kathleen, code is technology, thus business knowledge has to be isolated from it as well:
Combining business logic with any technology dooms it to be rewritten from the ground up when we get a new technology – and code is technology.
[…] You cannot combine code with business logic.
The shiniest, prettiest toys and languages are tomorrow’s legacy.
Business knowledge should rather be stored “in the places it resides: database structure, service contracts, test definitions, logic rules, workflow, business object code, validation rules, authorization guidelines, user interfaces, etc.” One could argue, however, that whatever the place we choose to isolate business information, it is still based on a technology that cannot escape change. Nevertheless, there is one key difference between using code “as core way of expressing intent” and storing expressions of the intent with a given syntax:
You can recognize, categorize and morph declarations. Sure, the syntax of any declaration is based on the technology its intended for. […] But, any metadata worth its salt can be transformed into any other metadata syntax.
[…] By separating out the known aspects of the job we’re doing – we can use it or not use it in the next great thing.
This way, Kathleen advocates for code generation as a means for extracting and separating business logic from code. Based on her experience, she argues that “even the best normal development efforts are worse than mediocre code generation development”. The most professional team using agile methodologies can succeed in delivering quality software on time, but in the eyes of Kathleen Dollard, this would still be a failure because “the whole thing will start over with a new technology.”
It is important to highlight that in a generated system, code still plays a critical role. Inability to map bugs was one of the reasons of the 4GL disasters in the eighties. Generated code allows avoiding this pitfall, because it is actually “how the system tells you what it’s doing”, which is absolutely crucial for debugging. Hence, Kathleen describes code as “the necessary evil” and argues that it should be treated as such.
She emphasizes that such approach requires a fundamental shift in the way we conceive programming, significant leadership as well as appropriate tools that would allow doing code generation well. Kathleen argues that today, “.NET is not an inoculation protecting your project from technology change”. It actually speeds up its pace. However, there are already some premises for a more widespread use of code generation.
On could mention the entity framework for mapping to metadata or XML literals which have, according to Kathleen Dollard, “amazing possibilities for code generation” and the potential to “unseat XSLT for complex generation.” Kathleen expects the area of code generation to be very dynamic in the following years. This should get us closer to proper development which, she believes, would be based on “a combination of code generation for all the stuff its dumb for us to write married to a highly morphed BDD for all the code we do have to write.”
RelatedVendorContent
Performance Management and Diagnostics in Distributed Java and .NET Applications
Free $40 SOA Demystified Book Offer
Agile Development: A Manager's Roadmap for Success
Related Sponsor
Red Gate Software makes ingeniously simple tools for over 500,000 SQL Server and .NET professionals.
Isn''t that obvious?
by
Markus Voelter
Posted
Dec 21, 2007 12:55 PM
Re: Isn''t that obvious?
by
Bruce Rennie
Posted
Dec 21, 2007 1:53 PM
Re: Isn''t that obvious?
by
Andrej Marjan
Posted
Dec 21, 2007 4:50 PM
Re: Isn''t that obvious?
by
Michael Hunger
Posted
Dec 21, 2007 7:23 PM
Re: Isn''t that obvious?
by
Sadek Drobi
Posted
Dec 24, 2007 9:40 AM
Re: Isn''t that obvious?
by
Jonathan Allen
Posted
Dec 21, 2007 7:30 PM
Re: Isn''t that obvious?
by
Sadek Drobi
Posted
Dec 24, 2007 9:50 AM
This concept is fundamentally flawed
by
Christian Schneider
Posted
Dec 22, 2007 4:19 AM
-
Why is that anything new?? Isn't it obviously a good idea to separate concerns (among them business logic from technology)? And sure, code generation is a good thing to do that. The MDSD/DSL community has been preaching that for ages. Why is this newsworthy? I don't get it. Markus
-
I don't know about newsworthy but, given what I've seen in a lot of .Net shops recently, it obviously is a lesson not fully absorbed by many developers. But, there is a tool you can use that will increase the likelyhood that developers will separate the business logic: unit tests. Insist on unit tests (true unit tests, a la the Michael Feathers definition) for the business logic.
-
It's not new. There's just another wave of "IT" folks who lack the quality CS education to know, or the native intelligence to discern for themselves, that whatever you implement your rules in, is *code*. Whether you compile that down to C# or Java or Ruby or some bytecode or some instruction set that a piece of silicon can execute directly... is immaterial. It's the same thing, at a different level of abstraction. This reeks of the old notion of "automatically generating" application code from formal specifications while ignoring the hard, error-prone work of writing the spec in the first place -- only without the mathematical sophistication. Note that I'm not addressing the call for a separation of concerns. I'm addressing the thoughts behind the rather depressing statement "You cannot combine code with business logic."
-
Sure its obvious. The question as always is, where to stop. Which business aspects are so concrete and complex that their representation in abstract models is much more complicated than in code itself? How often is it really needed to transform a software system to a complete new technology or language (something like the question of database portability) ? I think being able to transform your current business logic representation to another form is enough. So keeping your code clean, well structured and of the same level of abstraction within one unit certainly helps there. You have the same problem when transforming models or DSLs. If your model is to complex transforming it to another representation is to much effort to be done. And if you keep all your logic in abstract models a suitable projection to the shiny new technologies is also a must. Another thing that comes to my mind. As we all know business requirements and so business logic changes all the time. So keeping up with this change also allows you to explore new opportunities to express the business logic contained in your system. No one forces you to stick to the old ways of expressing these values. Michael
-
Not obvious, just stupid. The source for your code generator is just that, source code. Compilers really are just glorified code generators. In fact, many compilers simply turn one language into another. Phasing out that mainframe? Just write a COBOL compiler that targets .NET. Tired of using .NET? Write a compiler that takes IL code spits out JavaScript. I love code generators, but lets be honest. They are not a silver bullet that will make your code future proof.
-
If you do not use code to store your business logic then how do you store it? You will always need a kind of language. It can be graphical or textual, imperical or functional. So instead of using Java code you would in her concept just use another kind of code. One thing you can achieve with this is finding a better domain specific language for your business logic. But then the core concept is not code generation but domain specific language. Code generation is like described in the comment of Jonathan just another form of compiler. Instead you could also use an interpreter for your dsl. The crucial thing for domain specific languages will be IDE and especially debugger support. The other problem is that you need extremely skilled developers that build your dsl. If you don´t have them the chances are high that the dsl itself will be you biggest legacy in short time.
-
Sure its obvious.
What is the "it" that is obvious? That fact that we still need code anyway? The fact that code itself IS a technology that should be abstracted? Or the fact that the most successful IT project is a failure? How many applications has been completely rewritten tagging the previous "successful" code as legacy just because it should be ajaxified? What is obvious for me is that NON of these is obvious for plenty of enterprises i pass by for consulting!!! And in case it is so "of course it is of course obvious" then why do we write books about that i wonder... -
Of course they are not silver bullets, but how about a script that will generate the Entity framework mapping out of HBM files? How could we ever do that?It is by identifieng this code from the rest of the code. That can be applied to GUIs, Workflows and a lot of other parts of the application.
8 comments
Watch Thread Reply