By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,889 Members | 1,373 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,889 IT Pros & Developers. It's quick & easy.

Code Generation

P: n/a
Hello,
I hear some hypes about creating code to generate C# or VB .NET code, that
is, code generation (sounds straight forward enough). I haven't really seen
how it's done in real world. I'm wondering in what kind of situation code
generation makes most sense. I'm think that sort of tricks can be done in
relation to unit testing. Has anyone done code generation and can you share
your story with the rest of the world?

TIA
Nov 15 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Hello

In my case, I used code generation to generate data access classes in c#.
I made a tool that reads the database schema (tables, fields, primary keys,
foreign keys, data types, etc) and generate one class per table with private
fields holding the data, and public properties to access these fields. And a
method for insert, update, delete from datable

The advantage of doing this rather than using a dataset / datatable is first
speed (in data sets all data are stored as objects, which means a lost of
type casting / boxing / unboxing occurs when reading and writing data in the
dataset.) and compile time type checking.

Best regards

"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Hello,
I hear some hypes about creating code to generate C# or VB .NET code, that
is, code generation (sounds straight forward enough). I haven't really seen how it's done in real world. I'm wondering in what kind of situation code
generation makes most sense. I'm think that sort of tricks can be done in
relation to unit testing. Has anyone done code generation and can you share your story with the rest of the world?

TIA

Nov 15 '05 #2

P: n/a
Tool used to build software for the business, using code generation

http://www.manager-erp.com/eng/products/its/platform/

"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Hello,
I hear some hypes about creating code to generate C# or VB .NET code, that
is, code generation (sounds straight forward enough). I haven't really seen how it's done in real world. I'm wondering in what kind of situation code
generation makes most sense. I'm think that sort of tricks can be done in
relation to unit testing. Has anyone done code generation and can you share your story with the rest of the world?

TIA

Nov 15 '05 #3

P: n/a
Excellent article from MSDN:
http://msdn.microsoft.com/msdnmag/is...n/default.aspx

It is commonly used to generate data access layer code, or simple user
interface code (add/update/delete/list for database table operations, for
example).

Hope this helps,
--- Nick

"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Hello,
I hear some hypes about creating code to generate C# or VB .NET code, that
is, code generation (sounds straight forward enough). I haven't really seen how it's done in real world. I'm wondering in what kind of situation code
generation makes most sense. I'm think that sort of tricks can be done in
relation to unit testing. Has anyone done code generation and can you share your story with the rest of the world?

TIA

Nov 15 '05 #4

P: n/a
Ditto on data access. The code generation for strongly typed datasets that
comes with VS.Net doesn't meet our needs, so we generate code that provides
strongly typed data access for all of the tables in our database.
"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Hello,
I hear some hypes about creating code to generate C# or VB .NET code, that
is, code generation (sounds straight forward enough). I haven't really seen how it's done in real world. I'm wondering in what kind of situation code
generation makes most sense. I'm think that sort of tricks can be done in
relation to unit testing. Has anyone done code generation and can you share your story with the rest of the world?

TIA

Nov 15 '05 #5

P: n/a
That's interesting.
What about code generation in relation to declarative programming? Do
you know anything about it?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #6

P: n/a
I'm afraid not. If you could throw a "for instance" at me, it might help.
"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:e8**************@tk2msftngp13.phx.gbl...
That's interesting.
What about code generation in relation to declarative programming? Do
you know anything about it?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 15 '05 #7

P: n/a
Thanks for your reply.
OK, for instance, let's say in the design phase, you declare all the
classes and their members in a document. The document could be a
specially made Word document. From there, you'd generate code out of the
document. That way, especially in a regulated environment, the document
and code go together very well. Of course, we could generate document
out of the code, but that's against the concept of declarative
programming and everyone of us know that catching any logical errors in
design phase is much cheapter than catching them in later phase.

The reason I'm interested in this that Scott Hanselman (RD in Oregon)
mentioned about it in .NET Rocks radio show. And I'm basically tortured
by the amount of documentation I have to do after I code at work as
well...

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #8

P: n/a
Now I understand. We chose to purchase on that one:

We are just now beginning to implement Rational XDE. I haven't used it
enough to give a good review, but it does a lot of what you are talking
about.

It's a UML modeling tool, and (unlike Visio) it supports round-tripping.
XDE actually runs inside of VS.net, so the diagram surface is just another
tab in the code editor.
I can, for example, sketch out a class in a class diagram, and instantly see
the code declarations. If I put text in the documentation window for the
UML diagram, it inserts that text as a <summary> xml comment in the code.
If I modify the code directly (example: I add a helper method that doesn't
really affect the architecture of the class), the diagram is instantly
updated to show the new method.

Looks pretty cool so far -- it better be; it was not cheap.

On a more general note, the problem always seems to be in maintenance. For
some types of classes (especially those with no artificial behavior), you
can just always change the document and regenerate new code wholesale.
Often though, I seem to run into situations where some behavior of code that
you want to generate needs to be tweaked or customized in some way. Unless
the document is rich enough to catch all of the important nuances, you won't
be able to overwrite the existing code with newly generated code without
fear of losing some manually applied changes to the method bodies. On the
other hand, if the document format is rich enough to capture all of the
important details, at what point does it cease to be a document, and become
the programming language? i.e.: when does the level of detail in the
document become so rich as to drown out the clarity that you were trying to
create in the first place?

My colleagues and I have been debating this a lot lately, as we try to
figure out exactly what role our UML models will have in the organization.
The two extremes seem to be
(super weak): the drawings are really just reference material, created after
the fact
(super strong): all code is generated from the models with no manually
entered code.

Now obviously, those are at the very edges of the spectrum, and the right
balance for us lies somewhere in the middle. We've been trying to figure
out exactly where that point is.

FWIW: in our data classes (which we generate from an inhouse generator), we
found that we do have to modify behavior in some cases. Our solution was to
generate 2 levels of code: an abstract class that is "generate only". It
will always be overwritten, and hand-coded sections are not allowed (all the
strong typed field definitions, ect go here) and layer 2, the
implementation, which is auto-generated once, and then developers are
allowed to override methods etc to modify behavior. There are some inherent
problems with just doing that, because in the future the data model might
change (incremental and major upgrades), so we had to write some custom
merge code for handling changes due to modification to the database
structure. It was kind of a bummer, but we've got it working pretty well
now. Of course, Whidbey, generic types, and partial classes would have
helped us out a lot with some of this stuff.
"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Thanks for your reply.
OK, for instance, let's say in the design phase, you declare all the
classes and their members in a document. The document could be a
specially made Word document. From there, you'd generate code out of the
document. That way, especially in a regulated environment, the document
and code go together very well. Of course, we could generate document
out of the code, but that's against the concept of declarative
programming and everyone of us know that catching any logical errors in
design phase is much cheapter than catching them in later phase.

The reason I'm interested in this that Scott Hanselman (RD in Oregon)
mentioned about it in .NET Rocks radio show. And I'm basically tortured
by the amount of documentation I have to do after I code at work as
well...

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 15 '05 #9

P: n/a
You are absolutely right about "balance". If we have to explain everything
we code, then why does even document exist, right?

I've used XDE for some time now. So far, it's nothing but a diagram tool
that allows me to create diagram so that I can communicate with my
colleagues on object model. Maybe it's my ability to really look for good
ways to utilize it, but I haven't found it very useful. It IS a cool tool
though.

"J.Marsch" <je****@ctcdeveloper.com> wrote in message
news:Og**************@TK2MSFTNGP09.phx.gbl...
Now I understand. We chose to purchase on that one:

We are just now beginning to implement Rational XDE. I haven't used it
enough to give a good review, but it does a lot of what you are talking
about.

It's a UML modeling tool, and (unlike Visio) it supports round-tripping.
XDE actually runs inside of VS.net, so the diagram surface is just another
tab in the code editor.
I can, for example, sketch out a class in a class diagram, and instantly see the code declarations. If I put text in the documentation window for the
UML diagram, it inserts that text as a <summary> xml comment in the code.
If I modify the code directly (example: I add a helper method that doesn't
really affect the architecture of the class), the diagram is instantly
updated to show the new method.

Looks pretty cool so far -- it better be; it was not cheap.

On a more general note, the problem always seems to be in maintenance. For some types of classes (especially those with no artificial behavior), you
can just always change the document and regenerate new code wholesale.
Often though, I seem to run into situations where some behavior of code that you want to generate needs to be tweaked or customized in some way. Unless the document is rich enough to catch all of the important nuances, you won't be able to overwrite the existing code with newly generated code without
fear of losing some manually applied changes to the method bodies. On the
other hand, if the document format is rich enough to capture all of the
important details, at what point does it cease to be a document, and become the programming language? i.e.: when does the level of detail in the
document become so rich as to drown out the clarity that you were trying to create in the first place?

My colleagues and I have been debating this a lot lately, as we try to
figure out exactly what role our UML models will have in the organization.
The two extremes seem to be
(super weak): the drawings are really just reference material, created after the fact
(super strong): all code is generated from the models with no manually
entered code.

Now obviously, those are at the very edges of the spectrum, and the right
balance for us lies somewhere in the middle. We've been trying to figure
out exactly where that point is.

FWIW: in our data classes (which we generate from an inhouse generator), we found that we do have to modify behavior in some cases. Our solution was to generate 2 levels of code: an abstract class that is "generate only". It
will always be overwritten, and hand-coded sections are not allowed (all the strong typed field definitions, ect go here) and layer 2, the
implementation, which is auto-generated once, and then developers are
allowed to override methods etc to modify behavior. There are some inherent problems with just doing that, because in the future the data model might
change (incremental and major upgrades), so we had to write some custom
merge code for handling changes due to modification to the database
structure. It was kind of a bummer, but we've got it working pretty well
now. Of course, Whidbey, generic types, and partial classes would have
helped us out a lot with some of this stuff.
"Hayato Iriumi" <hi*****@hotmail.com> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...
Thanks for your reply.
OK, for instance, let's say in the design phase, you declare all the
classes and their members in a document. The document could be a
specially made Word document. From there, you'd generate code out of the
document. That way, especially in a regulated environment, the document
and code go together very well. Of course, we could generate document
out of the code, but that's against the concept of declarative
programming and everyone of us know that catching any logical errors in
design phase is much cheapter than catching them in later phase.

The reason I'm interested in this that Scott Hanselman (RD in Oregon)
mentioned about it in .NET Rocks radio show. And I'm basically tortured
by the amount of documentation I have to do after I code at work as
well...

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!


Nov 15 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.