Geeks With Blogs

Joel Ross

I'm going to be doing a major revamp of the business and data layers of an application I have. Right now, it's mainly data readers and dataviews being used, with a few custom business objects. While it works, and is efficient for the task, I programming will be easier and less error prone if I can switch to a domain model with all business objects.

Which brings me to my question. Which is better? Code generation or O/R mapping? I'm a huge fan of CodeSmith, and recently got a license for version 3. I've generated thousands and thousands of lines of code with CodeSmtih, so I'm familiar with it. I've never done anything beyond a sample application with any O/R mapper, so I'm fairly new at it.

Here's where I see the advantages and disadvantages for each one. Let's start with code generation. You have complete flexibility. You can create your objects just the way you want them. You can inherit from your own base class, or not have one if you don't want one. The downside is that if you change your data model, you have to touch the objects to reflect those changes. Plus, while a tool like CodeSmtih is awesome, it can be cumbersome to create the initial template (hint: create a class the way you want it, and back into a template).

For O/R mappers, a lot require you use a base class that all objects have to inherit from. This limits your flexibility. Others have requirements on how you have to do things, which again limit your flexibility. The advantage is that there's basically no data layer - it's generated (usually on the fly) by the O/R mapping software, and "just works."

Right now, I'm leaning toward generating everything, but I can stil be persuaded. What's the best O/R mapper you've used (and remember, I'm cheap!)? Would you rather generate or map?

Technorati Tags: | |

Posted on Friday, March 3, 2006 9:44 PM | Back to top

Comments on this post: Code Generation or O/R Mapping?

# re: Code Generation or O/R Mapping?
Requesting Gravatar...
Personally, I am a fan of code generation. There are a few rules that you would need to follow though.

Use metadata to drive your code generation. Database system tables, make good sources for the metadata.

Protect your generated layers. You want to make sure that you can regenerate as needed. If you need to make any code changes to your generated code, either change the metadata or derive a new layer from your generated layer and make your code changes there.

In my opinion, code generation is also great for tedious code where best practices may change over time, such as data access, web service facade, etc. As best practices change, you can change the generator and then regenerate all of your code instead of rewriting all of your code.
Left by Nick Harrison on Mar 06, 2006 8:49 AM

# re: Code Generation or O/R Mapping?
Requesting Gravatar...
Good points, Nick.

I pretty much use a database for generating objects, so I agree there.

I think the use of partial classes in VS 2005 is a great way to protect your generated classes. You can still add custom functionality to the classes, and still be able to regenerate if needed. I good way to enforce that would be to make the generation part of the build process, so you know that no one is modifying the generated code. I think partial classes are a better option than inheritance - inheritance is great for morphing a base object into a more customized object, but this situation is exactly what partial classes were designed for.

In the past, we had a bunch of look up tables that we needed access to in our code, and those values rarely changed. Instead of trying to come up with some way to make the whole process database driven, we used code generation to generate either enums or constants, so we could refer to those values in a type-safe manner in the code. It worked out very well, and can be regenerated anytime those values change.
Left by Joel Ross on Mar 06, 2006 9:08 AM

Your comment:
 (will show your gravatar)

Copyright © Joel Ross | Powered by: