Hi Frans, comments are inline.
and those are? :) Isn't the code generated also OO? Mind you: your
client doesn't give a **** about how you wrote the software, he just wants
software that solves his problems. So if you thought about a fancy
architecture with a lot of services and all the latest buzzwords, it's not
important. What's important is that what's used makes things easier and
better
to understand what's going on, i.o.w.: no surprises, no traps.
Let me just say that I do not feel comfortable about injecting business
logic related code into generated ORM classes. Even if the generated code is
OO (which is true in your product's case:) I am not comforable with adding
behavior for purposes other than persistence to that code. Since behaviour
can not exist on its own in an OO context, this implicitly forces me to
define domain objects as another set of classes. This leads to a situation
where I have two sets of classes that represent the same domain, but have
different responsibilities. One set covers business requirements, the other
covers persistence. I know that they can be combined, but It feels cleaner
this way. You are absolutely right about the client. They don't give ****
about the background work, and the whole point of this dicsussion, which has
been quite satisfactory for me, is about making MY work easier :) The
missing benefits from OO are motly about being free about the design domain
classes. Generated code comes in a particular structure, which you can
contribute/extend, but it has an existing inheritence structure anyways. the
app I've mentioned before uses state pattern for example, and injecting this
into OO generated code is not as natural as designing it from scratch by
looking at requirements. One more thing, keeping ORM generated classes
without business logic has the advantage of having an easily serializable
layer, which works great for me.
I'll give you the following advice, even if it sounds weird. Design
an
abstract entity model first. Just try it, use Object role modelling or NIAM,
with inheritance etc.. Then convert it to both classes and tables.
Ok, this is a n advice which I'll put to test, and I'm glad to hear
it. This overall discussion has been great actually!
Cheers
Seref
FB
===================================
This list is hosted by DevelopMentor(R) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
