Thank you for the interesting information. The only question is… Do you really think such code generation technique is convenient to use and extensible enough?
But, first of all, I definitely have doubts regarding the statement that “The power of code generation, is code – reuse”.
I used to think of code as a set of instructions on the language which is actually interpreted/compiled and executed.
Let’s assume we have entity A and entity B and we want to generate business objects for these two entities. As far as I understand, after the entities are processed by your code generation tool we will have two identical code files for the two entities with the only difference in the name of the actual class. And we will have the same templated code stamped numerous times for each new entity.
But what about inheritance and usage of generics? Is there a notion of templates’ inheritance in nVelocity templating engine? Can I have a template for entity B to be inherited from template for entity A? Or, from different point of view, is it possible to say, using this mechanism, that entity B is derived from entity A?
If not, then I would not name it “code reuse”. I’d say it is quite the opposite – code duplication and I do not see code reuse neither on the templates’ level nor on the level of the resulting generated code.
From the other perspective, it seems to me that if you have exactly the same code generated for different entities it is really difficult to get optimal performance.
I would say that this pattern is doomed to be buried under the heap of special cases, custom attributes, ad hoc templates, discrepancies between the generated code and the one edited manually, and sooner or later it’ll become very-very difficult to maintain the mechanism.
But, sorry, of course I may be wrong, so long live DTG:)
As far as reuse goes, I can definitely see where you’re coming from. For what seamless uses the dtg for (data access), I think there exists much better techniques to use (NHibernate for example) which eliminates the need to generate mapping code, and allows greater flexibility in maintaining the software. We already see in our code for example in VendorLocation which you’ve touched a lot, where adding a simple property requires changes on many many many many files. I think something is definitely amiss there. Unfortunately, I was not with Seamless when they picked how to do persistence
Template inheritance is a very interesting topic to me… I assume you’re aware of the Django framework, and the .Net port of it (NDjango)… I think it is a very good candidate to replace NVelocity as our template processor, for that very reason. I’m interested in your thoughts about code generation, in general… Do you believe that it is a sign of bad design? I mean, if you have a situation where code generation seems like a good option, is it because you’ve simply not modeled the problem correctly with inheritance or with application of some well thought out design pattern?
You see, I am not much of an architect. In fact I am not even a back end developer. I am front end developer with all my skills focused on UI implementation. Consequently, I by no means can judge code generation in general (that is to indicate it as a sign of a bad design).
In my comments I was mostly interested in question: whether you think it is convenient to work with?
Basically I just do not like the feeling that the code is written for me using some predefined set of rules. I do not feel that I am in control of the process. If I want to extend the schema in some unpredicted way then I must write another set of rules over the existing one, and another one, and another…
And as it is with any layer of abstraction, the more you are getting involved in the process, the more intimate knowledge of the mechanism you must possess to be able to fix inevitable issues.
At some point, it may become clear that it would be much cleaner and simpler approach just to write the code for each separate case without attempt to generalize it, make it uniform and generate bulk of the code.
Mike,
Thank you for the interesting information. The only question is… Do you really think such code generation technique is convenient to use and extensible enough?
But, first of all, I definitely have doubts regarding the statement that “The power of code generation, is code – reuse”.
I used to think of code as a set of instructions on the language which is actually interpreted/compiled and executed.
Let’s assume we have entity A and entity B and we want to generate business objects for these two entities. As far as I understand, after the entities are processed by your code generation tool we will have two identical code files for the two entities with the only difference in the name of the actual class. And we will have the same templated code stamped numerous times for each new entity.
But what about inheritance and usage of generics? Is there a notion of templates’ inheritance in nVelocity templating engine? Can I have a template for entity B to be inherited from template for entity A? Or, from different point of view, is it possible to say, using this mechanism, that entity B is derived from entity A?
If not, then I would not name it “code reuse”. I’d say it is quite the opposite – code duplication and I do not see code reuse neither on the templates’ level nor on the level of the resulting generated code.
From the other perspective, it seems to me that if you have exactly the same code generated for different entities it is really difficult to get optimal performance.
In essence it reminds me about the discussion in one great article I read many years ago: http://www.joelonsoftware.com/articles/fog0000000024.html
I would say that this pattern is doomed to be buried under the heap of special cases, custom attributes, ad hoc templates, discrepancies between the generated code and the one edited manually, and sooner or later it’ll become very-very difficult to maintain the mechanism.
But, sorry, of course I may be wrong, so long live DTG:)
Hey Alexei,
Thanks for your comments!
As far as reuse goes, I can definitely see where you’re coming from. For what seamless uses the dtg for (data access), I think there exists much better techniques to use (NHibernate for example) which eliminates the need to generate mapping code, and allows greater flexibility in maintaining the software. We already see in our code for example in VendorLocation which you’ve touched a lot, where adding a simple property requires changes on many many many many files. I think something is definitely amiss there. Unfortunately, I was not with Seamless when they picked how to do persistence
Template inheritance is a very interesting topic to me… I assume you’re aware of the Django framework, and the .Net port of it (NDjango)… I think it is a very good candidate to replace NVelocity as our template processor, for that very reason. I’m interested in your thoughts about code generation, in general… Do you believe that it is a sign of bad design? I mean, if you have a situation where code generation seems like a good option, is it because you’ve simply not modeled the problem correctly with inheritance or with application of some well thought out design pattern?
Again thanks for the comments!
Mike
Hi Mike,
Thank you for your response.
You see, I am not much of an architect. In fact I am not even a back end developer. I am front end developer with all my skills focused on UI implementation. Consequently, I by no means can judge code generation in general (that is to indicate it as a sign of a bad design).
In my comments I was mostly interested in question: whether you think it is convenient to work with?
Basically I just do not like the feeling that the code is written for me using some predefined set of rules. I do not feel that I am in control of the process. If I want to extend the schema in some unpredicted way then I must write another set of rules over the existing one, and another one, and another…
And as it is with any layer of abstraction, the more you are getting involved in the process, the more intimate knowledge of the mechanism you must possess to be able to fix inevitable issues.
At some point, it may become clear that it would be much cleaner and simpler approach just to write the code for each separate case without attempt to generalize it, make it uniform and generate bulk of the code.
Again, if you have time to read an article which I referred to in my comment (http://www.joelonsoftware.com/articles/fog0000000024.html) you’ll understand the ideas I am trying to express.
Thanks,
Alexei
It just does not