A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
In a new project,we are planning to use a code generation tool,which based on database schema will produce DAL,entities layer etc.The advocates in the team say that it will save us doing lot of mundane tasks like writing classes with properties,data access methods,validations etc.
The issue I see is that we are tying ourselves to the tool way of doing things.What other issues can crop up? Have you used such tools?
Thursday, July 26, 2007
If you pick a language, you're "tying" yourself to the language. You'll usually have an OS API that you're "tied" to as well. Code generation tools are just a compiler for another language - and if they get you a better product faster, so what?
(The trick, of course, is to actually evaluate the tool and determine its limits and flaws, rather than just read the half page marketing brochure with pictures of half naked girls. In fact, if they have any pictures of smiling happy models in any state of dress, it's probably a bad sign.)
You're a professional - you need to know and understand your tools, not fear them.
Thursday, July 26, 2007
We use such a tool with some of our .NET stuff and it's an excellent way to quickly get the DAL up and running. Plus, with partial classes, it's easy to extend what's been spat out by the code generator, so you're not totally locked into its way of thinking: you can supplement and tweak on a per-object basis as required.
Our team has used code generation tools on a large number of projects dating back about ten years. I've never had any reason to complain. At this point we've got some very mature, stable, and efficient templates covering a lot of useful cases.
I wouldn't look at this approach as a way to construct full-featured applications, but it is a great approach for implementing certain repetitive pieces. Try it out and see...
"If you pick a language, you're "tying" yourself to the language. You'll usually have an OS API that you're "tied" to as well. Code generation tools are just a compiler for another language"
Unfortunately, most code generation tools work from a language that is severely limited, often not even Turing complete (much less as expressive and versatile as any real programming language).
The problem I have always had with code generators is that you rapidly run up against things that require you to edit the generated code (rather than editing the input to the code generator itself) which turns every build process into a painful ordeal of re-applying modifications to the generated code files, often manually. Let's not even consider what happens when the next version of the code generator is released and your current set of modifications can't be easily applied to the new generated output.
I've also seen far more errors in the output of code generators than I have in the output of compilers (though I have seen a few compiler output errors, as well, and they were a royal pain in the ass to track down and work around), which only makes me more distrustful of code generators.
All of that said, I have found one good application of code generators: if you are writing most of your product in some high-level language (L) and you have a code generator (G) that can produce code in L for some small but particularly difficult portion of your product, then it is fine to use G to produce some of your source code. The main reason that this is not a problem is that you, presumably, already have experts on L on your team, and they could treat the output of G as just another set of legacy code in case G is discontinued or changes in some other way that orphans your application.
Thursday, July 26, 2007
"The problem I have always had with code generators is that you rapidly run up against things that require you to edit the generated code (rather than editing the input to the code generator itself) which turns every build process into a painful ordeal of re-applying modifications to the generated code files, often manually. Let's not even consider what happens when the next version of the code generator is released and your current set of modifications can't be easily applied to the new generated output."
I wrote a code generator that generated some of the code for forms in Visual FoxPro. The source contains directives for inserting generated code and a terminating directive for each code-generating directive. The directives are VFP comments and appear in the generated code. When the code is regenerated, any code between a directive and its end directive is assumed to be generated code. This code is replaced with the new generated code. Any other source code is passed through unchanged. I find this works well for me.
"The problem I have always had with code generators is that you rapidly run up against things that require you to edit the generated code (rather than editing the input to the code generator itself) which turns every build process into a painful ordeal of re-applying modifications to the generated code files, often manually."
So use a Perl script or equivalent to apply your changes, and have it run automatically as part of the code-generation stage of the build.
Doing routine work manually is a sign of a programmer who doesn't understand the purpose of programming.
Friday, July 27, 2007
Yes, as a programmer I need not fear tools,and should understand their power and limitations.Also,using code generation for some part of application is a good idea.We are going to use nettiers which generates DAL,Entities layer etc.
Only fear I have,is that we have not completely understood the complete flow of code generated(mechanics of how things work).So,my fear is that if at any point in development we get stuck,we might have to spend time to get under the skin of code generated.
Friday, July 27, 2007
"You're a professional - you need to know and understand your tools, not fear them. "
It's not a matter of fear. It's a matter of having a perfectly good set of tools already that you can get the job done with. Is there a need to then learn how to use a completely new tool to do a small portion of a job when you can get by with what you already have? Sometimes it's better and sometimes it's not. It all depends on what the tool does and the person using the tool.
Code generation in the hands of poor designers ends up being a real mess. And I've been involved with at least three products that used code generation where it wasn't a defined part of the process (templates aren't in source control, etc.). Eventually, templates get lost or the guy that "does the code gen thingy" leaves and everyone else gets left holding the bag. And because code generation of crappy code is so painless, you end up maintaining really crappy code by hand for the life of the product.
I've been burned by code generation way too many times. To me, it takes much less effort to just design a good DAL using OOP that negates the need for such tools in the first place. If you can create a simple DAL that is easy to use and makes code generation obsolete, why would you even think about picking up some other tool and having to learn its nuances?
That's my two cents. And don't even get me started on the evils of using code generation to create GUI's! ;)
Friday, July 27, 2007
I used a vendor framework that generated data accessors from Rose models - export model to XMI, XSLT to Java. They were very effective most of the time, and there was a clean way to implement custom hand-made accessors for some or all functions. They had XSLT scripts to generate UDB, Oracle, MQ-Series and other physical IO behind the same interface.
The same framework also generated abstract services and "business delegate" style proxies for them. The generated class was abstract and we did all coding in concrete implementations so repeating the gen never overwrote custom code. The proxies could use different protocols to call the service: local Java, remote EJB, RMI, XML/HTTP, raw sockets, etc. The client code didn't need to know.
I've been a fan of generating code since the 80s, but make sure you generate a great design.
Saturday, July 28, 2007
"I've been burned by code generation way too many times. To me, it takes much less effort to just design a good DAL using OOP that negates the need for such tools in the first place."
What is a "DAL"? I think I have found an expansion (Data Access Layer), but no decent definition. How would it be necessarily related to code generation anyway?
A DAL is a data access layer. Although you can use code generators to create any type of code, I've seen them used mostly to generate DAL's and related data code. So my statement about the use of good OOP design principles negating the need for code generation was referring specifically to the use of code generation of DAL's. Clear as mud right? ;)
Monday, July 30, 2007
In my experience, code generation works best when what's being emitted are not partial classes but abstract classes. This allows you to handle cases that the generated code doesn't by overriding properties and methods, and it doesn't break when you regenerate your code from the metadata.
But before I'd write a code generator, I'd make sure that someone else hasn't done it first. I'm thinking here of ADO.NET's strongly-typed DataTable classes, which, while they have their issues (insert rant about Nullable<T> here), do an awful lot of what the code generators I've written used to do.
Wednesday, August 01, 2007
I've been looking at a project called Qcodo: http://qcodo.com/.
Qcodo generates code, but it's not just a code generator. As Qcodo developer Mike Ho puts it:
"Qcodo is a PHP development framework. Within the framework (specifically the ORM to aid with Model programming in a formal MVC architecture), it utilizes code generation constructs. But note that this is just part of the framework on a whole."
If you are looking to make CRUD apps, Qcodo is amazing.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz