> Many of the advantages I'm trying to preserve by modelling using design
> patterns and common OO concepts, are about "coding". More maintainable code
> and more efficient changes to code (in terms of man hours) is my primary
> point which is in favor of OO approach.
If OO brings you better maintainable software in this case, OO is a
good choice. If it gives you less maintainable software, don't use OO. Using
OO doesn't give you a turnkey solution to maintainable software, neither does
an API in a DB consisting of 10K procs, one has to WORK to make software
maintainable, it has less to do with the paradigm used, but more with the fact
that decisions made are made for a reason and that the decisions made are
documented, that the alternatives and why they were rejected are documented,
that answers to the simply question "Why?" is answerable by a person who will
work on the software in 2015, when you're sitting in the sun on the beach on
the Bahamas and cellphones are out of reach.
> I'm just saying that, by using DB concepts (types, relations) as the primary
> modeling approach, and generating OO code from this model, we loose some of
> the benefits of OO design.
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.
tables and fk constraints aren't the elements classes are directly
based on. They're based on the reversed engineered model at an abstraction
level ABOVE E/R model (so it can contain inheritance etc.).
> My request for comments is about the following scenario. By adopting OO
> based design for domain, you can choose to completely ignore the requirement
> for persistence, accept it as a service actually, and use all the things
> like inheritence, interface based design, particular patterns etc..
Those are implemenatation specific elements, and can work perfectly
fine with classes which represent entity definitions. After all, every single
code construct's reason to be there is that you can deal better with the
complexity you're facing. If applying a construct doesn't make the complexity
you're facing less complex, don't apply it.
> After you've done this, you have a set of classes, and you actually have two
> choices.
>
> 1) you can now forget about all these classes, and design a db schema based
> model for the domain, as if you are doing the DB oriented modelling. After
> this you generate OO reflections of your DB model by reverse enginering this
> schema, and now you have two sets of "domain classes". One set is build on
> OO concepts, and the other one is mappings to OO concepts from DB concepts.
> A tool oriented summary is like this:
>
> [Classes generated from UML] <------->[connector
> layer/service/class]<------------> [classes generated from DB
> schema]<----------->[ORM services]<--------->[DB]
> Here, there is a possibility of overlapping, like very similar classes in
> both UML generated set and ORM generated set. But when inheritence and other
> OO concepts are used heavily in OO based set, the distinction is usually
> clear. Here, ORM based classes become kinda DTOs for DAOs, where DAO pattern
> is encapsulated in connector layer.
> Do you think the architecture above is overkill?
Yes
> Do you think that instead
> of modelling DB by looking at the domain, we can model it as using the class
> designs as inputs? I am trying to see if I can justify the appoarch above, I
> guess the only way to do that is to give it a try in a moderate sized
> project, which I have at hand at the moment, but still your opinions would
> be quite valuable.
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.
How you physically implement these types, i.e. if the 'Customer' class
inherits from a central base class, or from nothing (because for example POCO
is the norm), that's not important, as long as 'customer' represents
'customer', and not something that's only true in the reality of the class
model, because you then miss something essential: the conversion rules how to
come from CustomerX to customer and vice versa.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
