Joanna said:
Database design used to be the standard, well-proven basis for non-OO
applpications; I know, I was weaned on Logical Data Structure diagrams.
But where do you put the code that manipulates the data ?
Please don't tell me you use data-aware controls directly connected to
database tables and write the code in event handletrs on the forms!!
)
Why are some people just always grabbing an extreme end of the spectrum
to make their point. You know very well there are a lot of different
solutions to place behavior correctly.
In fact, there are 3 kinds of behavior on data:
- attribute oriented behavior (ID > 0)
- entity wide attribute oriented behavior (order date <= shipping date)
- cross entity entity oriented behavior (customer is gold customer if
ordered at least 10 orders with producs a, b or c in the last X months)
the first two are perfectly placable inside entities, the 3rd isn't, as
you run very soon into problems with fragmentation of functionality,
i.e.: you have a set of functionality defined and the implementation is
fragmented across various entities. This makes a system hard to maintain
Not all data in an application is stored in a database. In a well designed
OO application you may well have hundreds of classes that have nothing to do
with *stored* data.
No offence, but when I design a business application, I don't think in
classes or objects. I think in entities, their relation between them and
define them in NIAM/ORM models. The customer can perfectly understand
them, as they contain scentences, like "Customer Has Order", "OrderLine
belongs To Order". Throw in the good old stuff from mr. yourdon and you
can perfectly design your system, without having to go through the
awkwardness of using implementation details.
The fun thing is: the design of the application is abstracted: you can
check if it's correct without writing 1 line of code or even think of
which class has to inherit from which. The other fun thing is: if you
use these diagrams as the guides what you have to implement, you have a
1:1 projection of what you have designed onto an executable form of it:
the code and _vice versa_. This means that I can look into the code, and
go back to the abstract models because that connection is there. The
other way around is also possible.
This isn't science fiction, this is reality for system designers for
over 20 years. I know what the domain model is, and your reasoning comes
from it, but don't bring it as if before the domain model software
developers were just doing unstructured things without any theoretical
basis. On teh contrary.
The frameworks I have written to support my applications contain around 300
classes and interfaces.
that's nice, now let's look at what you have to do when I present you
an enterprise db with 1300 tables.
There is the Value Type Framework that gives me more metadata about my
business objects and their properties.
There is the Object Persistence Framework that allows me to write OO code
that knows nothing about databases because the OPF translates business
objects to/from database tables, generating SQL on the fly. I only ever use
one Query component, one Transaction component and on database component in
my entire application and frameworks combined.
So do I, though I do start from the relational model.
There is the MVP framework that allows me to replace my UIs without having
to change any of the code in either my business objects or the applications
that use them.
MVP framework, hmm.
But what you describe here is just normal n-tier goodness: you write a
BL layer which acts on its own, so you can place on top of it a gui tier
which can work on its own, consuming the services of the bl tier...
that's also ancient tech, and not OO related
How would I extract those classes and interfaces from a database ?
You have a system design, abstracted. That design learns you about an
entity 'Customer'. That's an abstract thing, it's build up from
attributes, like 'CustomerID', 'CompanyName' etc.. You know, the basic
CS stuff.
That model leads to a relational model. You can use that relational
model to build your entities, as they represent the same thing: the
entity. Then you write your BL tier which represents your application
functionality and you place the 3 types of behavior related to entities
at the right places.
DONE. No-one generates a gui from a db schema, as the gui should be
designed for useability and should be the frontend for the functionality
realized by the application. So on a screen you can for example have
customer AND order information. That's perhaps nice for the screen, but
you aren't storing that info together.
What about those applications that don't use databases ?
well, what about them?
MyGeneration does exactly that.
How does your software translate the Sales Order example I gave ?
Well, how does your software represent objectified relationships which
represent m:n relations?
A detailed aspect doesnt make something 'wrong', as there isn't a
'wrong' or a 'right' side here. The relational model approach has 30
years of proven technology on their side, you represent a new vision on
the matter. What's right and wrong is therefore a bit tricky to define,
as both camps will say the other side is wrong.
It's all about technical solutions for the data-access problem,
something which only exists in teh technical problem space. It doesn't
exist in the abstract functional problem space. There are different
solutions to that technical problem, and the one which fits with your
way of work depends on how you want to work, as there is no right or
wrong here. I wrote an article about that some time ago, you can find it
here:
http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx
Frans
--
