> > So, you still want to write a lot of entity classes, thousands
> > of lines of property get/set code and oh, for example xml /
> remoting support by hand?
> >
> > Code generation can help you get things done if you use the
> > right code generator, for example one which combines it
> with an O/R mapper core.
>
> Code generation for DAL is one thing, code generation for UI
> is another. As for the snippet generation for properties et
> al, that's what a snippet generator is for in your editor of
> choice. Heck, I did that in TECO in 79, so I think I get
> "code generation" at that scale.
You sounded like you didn't need code generation, yet, if you want to
use an o/r mapper you have to have entity classes, you
can't avoid that. These either have to be generated or hand-written. To
generate them, you need meta-data. Handwriting them is
tedious, especially for larger systems.
> What I DON'T find useful is "frameworks" that generate the
> same old basic site (or DAL classes or whatever) that don't
> really map to anything I can deploy in an end-user
> customizable environment. I do code for vertical markets,
> not one-off contracting or programmer tools, so I can't have
> people regenerate code when something needs to be customized
> at their end.
so, what will those people do then, hand-write code?
> I also don't find any value in the generation of DAL-layer
> DTOs from a "presumed fully designed" database schema. I'm
> much happier with business objects as POCOs that I can
> implement with NO database in existence, and eventually map
> them to whatever persistence is warranted.
No-one's stopping you from doing that. Though realize that by doing it
manually, you will lose time and thus money. It's
your customer who has to pay for that. Besides that, your handwritten code
isn't tested by default, you have to test it yourself,
and design it correctly. I.o.w.: you can't build on top of proven code. This is
different when you use code generation which
generates a framework for you which is proven and is tested.
> As for the idea that XML/Remoting object can be generated,
> color me gray with disappointment that you imply that those
> things are real-world usable. In my lifecycle, there's no
> chance that a database schema or today's POCOs are going to
> give me a stable interface that I want to program against. I
> would my rather model those things in a tool that works for
> that and then craft the XTOs that can do versionable
> contracts with them.
Only if you use contract-first services. Which is the best way to go,
we agree on that, but most people won't use that
today.
You also forget one thing: the relational database model is a result of
an abstract entity - relationship model, you know,
the same one you will use to build your POCO objects and relationships between
them. How would you determine that you need a
'Customer' which has a relation with 'Order' and an OrderDetailRow which has a
relation with 'Order' as well? Or that
SpecialCustomer is a subtype of Customer, and inherits the relations of
Customer, for example with Order?
So how can an abstract entity model not be a solid base to write your
code with? IMHO it's better to use a theoretical
proven model than to 'guess' which entities you need.
> I've generated code from UML diagrams (and roundtripped it
> nicely) using the latest Rational stuff, but that's pretty
> close to as far as I can go without dropping dangerously
> close to needing to attend Waterfall 2006.
Yeah, let's not think before we do, huh?
> Marc
>
> p.s. Frans, please don't coopt this thread to sell your
> EXCELLENT tool, I've used it, respect it, but I don't need it.
I'm not on this list to sell stuff. *sigh*. Am I now not entitled to
participate in a thread which touches the material I've
been working on since january 2003 full time? Oh my, next thing you know he'll
try to sell his work!!!111. :/ What would be the
reason, Marc, why I didn't add my standard signature to the posting I made?
Right! to avoid remarks about me trying to sell things.
It might not be clear, and it might sound arrogant, but I DO know a lot about
this stuff, but if you think it's better to stop
participating in these kind of threads and let just one side of the fence do
the talking, go ahead and say it.
Frans
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
