Hard choice but choice

Published 30 January 04 05:53 PM | despos

Kathleen says something important in her post about ObjectSpaces: "For almost all of us mapping is an issue resolvable at design time. Thus I think code generation is a much better model for most of us."

Runtime egg or design-time chicken?  

 

Comments

# AndrewSeven said on January 30, 2004 12:08 PM:

A runtime cost of +30%.

When I first heard that I was shocked. I would really like to know what it means.

Its normal to be slower than SQL direct, but is there an aspect of custom code/buisness objects that needs to be factored in?

I use the Data Access Application Block and SQL Server.
It is fast and it is really easy to use, can ObjectSpaces truly simplify my life more than this?

V Intedev had design time controls.
VS.Net lets you drag datasets and connections onto the design surface.
Both are/were pretty much just junk.

# Frans Bouma said on January 30, 2004 12:10 PM:

I don't understand the argument Kathleen is using. Although the mappings are done at design time, they are hardly an issue at runtime. What's the biggest bottleneck in O/R mappers is the generation of SQL.

The problem is: you can't do that up front. You have to build in some sort of SQL-JIT which caches often used query constructs and can construct a query faster each time it is executed.

# DinoE said on January 30, 2004 12:14 PM:

> Both are/were pretty much just junk.

100% agreed


> I use the Data Access Application Block and SQL Server. It is fast and it is really
> easy to use, can ObjectSpaces truly simplify my life more than this?

I was looking for an answer to a similar question. I believe the answer is in one of the bulleted points. "If you don't have a strong business layer, you probably don't need ObjectSpaces." And if you're looking for high perf, stick to ADO.NET and the DAAB is a great helper tool.

# Diego Mijelshon said on January 30, 2004 12:17 PM:

Any model that depends on code generation tools will fail.
When? The first time you have to modify something without the "magic tool".

# DinoE said on January 30, 2004 12:19 PM:

>>I don't understand the argument Kathleen is using. Although the mappings are done at design time, they are hardly an issue at runtime. What's the biggest bottleneck in O/R mappers is the generation of SQL. <<



Do you think exposing objects to let you refine SQL statements would be a form of optimization?
I'm thinking to properties like SelectCommand and the like out of ADO.NET adapters...

# Frans Bouma said on January 30, 2004 12:58 PM:

" Any model that depends on code generation tools will fail.
When? The first time you have to modify something without the "magic tool"."
Ever tried typing VB.NET code without VS.NET? Do it, I'm sure you will have a great time :) (ergo: all tools used to write a given source (be it a generator or an editor) are somewhat required to keep the source alive, even the original developer has to be kept 'alive' in some situations to keep a project up and running ;))

"Do you think exposing objects to let you refine SQL statements would be a form of optimization? I'm thinking to properties like SelectCommand and the like out of ADO.NET adapters... "
No not that kind of properties, more like access to query objects already created so you can just change the parameter values and re-execute the query, specification of query hints etc.

It's a tough call though. An update which updates all fields in a table can be reused for every update, which thus speeds up query creation. However updating all fields all the time can be slow too. It depends on what's slower to say exactly what will help you :)

# Kathleen Dollard said on January 30, 2004 04:33 PM:

Diego,

I don't think Code Gen is a "magic tool." Some vendors are selling tools that include code gen as a "magic tool" and they are simply wrong. There is nothing magic about code gen. It's a relativley simple technology with some astounding side benefits.

That said. Code generation is a permanent part of your process, in much the same way object oriented approach becomes part of your process, as well as your code. You do not want to make changes without the templates. Not because its difficult - its not. But because it breaks the regen cycle. Depending on the change, you'd do one of the following:

- make the change in the metadata and see it flow through your app
- alter the template, possibly bringing in a new template rule
- make the change in handcrafted code - specific code locations set aside for that purpose

# Kathleen Dollard said on January 30, 2004 04:41 PM:

Franz,

Understand that I am relatively new to OR/M and come at it from the purely pragmatic approach of buildng "normal" (whatever that is) business apps with a minimal of effort. Thus I assume I have much to learn.

In what scenario must you build SQL at runtime rather than design time? I have never encountered that - and assume its because there are more complex mapping scenarios. Are those scenarios mainstream or side cases?

I am pleased to hear the 30% is a myth. However, how can we justify comparing Object Spaces with DataSets rather than with a DataReader? If I use Object Spaces, it will replace a DataReader driven loading of business objects.



# Paul Wilson said on January 30, 2004 10:40 PM:

I think good quality code generation is far better than pure manual code creation and maintenance in repetitive situations, but I also think that O/R mapping is simply the next logical step in this evolution and thus even better -- if its good quality also. Why? If you agree you don't want to create and maintain code manually, isn't it even better to not have any code to generate or regenerate! That is what O/R mapping at its best promises -- no stored procedures or sql, nor DAL or other data-object mapping. By the way, its O/R mapping, not ORM, which is object-role modeling.

Leave a Comment

(required) 
(required) 
(optional)
(required)