Hi,

I am trying to do some more "pure OO" design for database app.
For single table, it is not that complicated. But how do you do
master/detail? How to create detail objects - with method from master object
or as standalone object?
If  I wrote Master.NewDetail then constructor for detail object must be
hidden/disabled.
If I do Detail.Create - then I must create number of checks to see if object
is added to master before I can do any operation with it (like Invoice - if
I do not know who is customer - written in master- I can not know what price
for item (detail) should be). And how much this gets complicated if you have
several levels of details.

This all looks to me as too much complications for nothing.
What do you get if you do code like this? It looks to me like complication
without much benefit in Delphi. If you do datamodule for data-access
(datasets) and separate components for bussiness rules enforcing, what do
you need more?
As I saw in Bold newsgroups, there is no easy way to create thin client that
works over internet like datasnap with socket connections. And it looks to
me that Bold thin client is not so thin.

Whole picture looks to me like this: somebody is trying to create Delphi
apps that are internally structured like java (smalltalk) apps. I think that
this is bad idea. Delphi is not java.

I did not intend to start flame war. I am just trying to figure out what can
I get if I try to implement stricter OO design for database apps.
Anyway, now I will put my asbestos suite on.

drazen

On Tue, 15 Apr 2003 12:04:59 +0200, "drazen" <draze...@hotmail.com>
wrote:

You are rediscovering the disadvantages of managing data through
imperative code and the disadvantages of the network data management
style.

SQL DBMSs were invented for eliminating that complications.

A {*word*99}.

Business rules should be enforced on the database server.

No, it is a lot better.

Regards
  Alfredo

news:3e9c11a8.15568095@newsgroups.borland.com...

snip

Agree with all except this one above. Speaking of n-tier app, business tier
should contain business rules. Also part of rules should be available to
client app through server methods (e.g. validation of product Id while user
enters data because my customers would be a little dissapointed if app tells
them "Dear user you misstyped 13 out of 22 product Ids in this invoice,
please correct" when he/she applies update to businees tier. Also, web shop
"select from list" style is not an option since there is too many products
and way too many invoices)

agree 150%

And I thought that here will be about zilion of flames. And got one comment
that confirmed my thoughts about objects and RDBMS.

regards
drazen

nothing.

For the same reason we don't write our own compilers, I
would recommend you use an existing framework like Bold.

<snip>

No this is not what they are trying to do.

In regards to Bold the goal is to:

A) Raise the level of abstraction that software is
developed at. This has the effect of making the software
easier write, easier to change and more likely to be
correct.

B) Implement an architecture where the cost to change
implementation details (like RDBMS, nTier, etc...) is
inherently cheaper than it would otherwise be.

C) Provide a layered approach to software architecture to
enhance maintainability and manageabilty.

D) Centralise business logic to enhance maintainability,
correctness and manageabilty.

Notice a common thread here? It's all about managing
complexity of modern software systems.

Just like a compiler reduces the need to use Assembler and
provides the ability to use higher level languages,
products like Bold enable you to develop using a high level
language again.

If you are finding this overly complicated it's because you
are trying to write the "compiler". You either invest your
time to do this and reap the benefits down the track, or
you use a pre-exisiting one and reap the benefits now. it's
your choice.

Cheers,

Anthony Richardson
www.boldbox.com

--

ELKNews FREE Edition - Empower your News Reader! http://www.atozedsoftware.com

For (some) small projects Bold IS overly complicated.

Unless time to learn/adapt exesting one consumes benefits. Again true for
(some) small projects. Learned it on my own experience :(

Absolutely not!
I use it for prototyping and for building small as well as large apps.  My
latest app had 3 classes!

I find it great for building small stuff where all calculated data is
derived for now, but I know that when I have a mass of data later it will be
slow and I can just chop out that derivation and make it more efficient with
calc on write or somesuch, and Bold will handle the data evolution and code
evolution for me.  No {*word*193} bugs elsewhere!

Bryan

There is a superb way of building thin clients.  Use Bold Express from
www.neosight.com - it integrates three major features into your Bold app,
using the Bold metadata to do all the work - you literally just plugin it
in.

Feature 1 - Web services over SOAP.  Set one tagged value in your model on
any methods you want to export, and Robert's your father's brother.
Feature 2 - Authentication and security - Low-level security and rights
checking, built into the Bold code generation.
Feature 3 - True thin client over HTML and javascript, with scalability up
to multiple back end servers if you require, running under Apache or IIS.

I use all three, by the way.

Bryan

news:3e9bd823$1@newsgroups.borland.com...

For creating new detail this is more sensible since because the Master can
insure the new detail gets a proper reference to itself. At the application
level there would never be a reason to create a detail class outside the
context of the master in this example.

The question you are really asking is "What good are objects?". The
complications you perceive are generally less so than developing without
using classes.

Nothing wrong with using datamodules, but I would put those datamodules
(their creation and use) under the control of the business objects.

This again sounds like you are questioning the whole idea of using objects
rather than comparing languages. Delphi, and the Pascal language it is based
on, has been object-oriented for about 14 years now, long before Java was
thought of.

What you get is another learning curve - no different than learning anything
new. The question only you can answer is whether you are willing to take it
on. If you are completely convinced that it is a waste of time then you are
pretty much guaranteeing any attempt to learn and use it will fail.

--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
Powered by Delphi and Interbase:
http://www.logicfundamentals.com/RadBooks.html
"Democracy, without that guarantee of liberty, is merely a method of
selecting tyrants." - Alan Nitikman

Hi drazen,

...

Out of curiousity, what do you mean by separate components ? Kind of Raize
Biz Components ?

Thanks.

--
Jerome

Take a look at the composite pattern, and also handling one-to-many
associations and using transient data objects in the OO literature.

It all depends of what you are trying to achieve.  For instance, if you are
writing a bug-tracking utility that can be put together in a couple of
days.  The RAD approach might work just fine there.  However, if you
are developing a manufacturing process control system where the
business rules are completely different depending on the various
product lines and hw components used in production, then you need a
way to structure/architect your application to facilitate reuse and
extensibility of those business rules.  If you go the RAD way, you end
up with Data Modules and Forms containing a lot of delegated,
context-specific code, serving disparate purposes (poor cohesion), that are very hard to reuse.  Choosing a more OO design/architecture
will provide you a better way to reuse, and extend your business
objects.  Along with improved cohesion and reduced coupling, which are the fundamental concepts of good ol' Structured Design and OOD.

..

I think you've misunderstood the whole purpose of OO.  The
shortcoming (or its virtue for RAD lovers :) of Delphi and its VCL is that
the RAD environment and data-access is build around the dataset
concept, and not a generic business object concept, nor does it
facilitate the building of business objects (well, maybe bold does that,
but I haven't used it yet ;).

Delphi zealots may take it as a flame, the way I see it is, if you don't
see a need for a stricter OO design in your application is because the
level of complexity in your application requirements is being met with
your current approach.  However, for other apps (like the example
above), the VCL/dataset/RAD approach leaves a lot to be desired.

I briefly looked at this product. Seems fine for thin client.

Except for price part.
How stable/buggy these products are?
How many users?
Will they be around in 3 years?

drazen

news:3e9c3321$2@newsgroups.borland.com...

news:3e9c432e$1@newsgroups.borland.com...

Yes, I use some modified version since I read Rays book. Also there is an
article on www.delphizine.com by Bill Tod about sharing business rules. I
use same concept in my apps.

drazen

news:3e9c54a8$1@newsgroups.borland.com...

I read GoF book, and some others. Also implemented lots of those patterns in
several GPS/GIS related project.
But with databases there is different story. There is RDBMS which is not OO
"ready". There are tools I am used to. Question is: is it worth effort and
money.
All answers I got are: Yes, do it, we are doing it succesfully.
Or like yours (next paragraphs): RAD is BAD (nice rhime).

Arguments i read till now: just learn and everything will be nice and easy.
Any concrete facts?

are very hard to reuse.

Maybe you did. I find it very simple to divide code in datamodules. And to
have simple calls from form into datamodule. I do not use any component from
datamodule in form. Delete button is hooked to Action, action says
Datamodule.DeleteRecord. Simple. Reusable for web interface.
All repeating code put in components and reuse it (I have number of places
where I check for valid product id in your app. And I use just one
component. And it is a Visitor pattern. Like other identificator
validators.)

Downside is that you can do hacks and go directly to datamodule.

fundamental concepts of good ol' Structured Design and OOD.

That is the point. I am not against OO. I am trying to find 'easiest way'.
All I can see for now is that this kind of architecture/framework is hard to
do with delphi. Having some experience with Delphi I still do not see
justification of going that way.

drazen

Most companies are not all that keen on divulging that info.

Who knows? If you had asked that question about Turbopower 3 years ago,
who would have said no?

Cheers,
Jim Cooper

____________________________________________

Jim Cooper      jcoo...@tabdee.ltd.uk
Tabdee Ltd      http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi with your Palm
____________________________________________

Not if you buy one :-) And they actually aren't that hard to write - I
had one working in 3 days. Obviously it didn't do all it eventually
needed to, but it did load/save/delete objects and collections of
objects. It also managed the situation you describe, which is nothing
particularly to do with business objects, but objects in general. The
way you manage "details" depends on whether the "master" should own the
"detail" or not. This is general OO design.

Then don't do it. However, the basic problem, which some contributors to
this group seem not to be able to grasp is this. Relational-type
databases (and I don't care to get into a hair-splitting contest over
what one is or isn't - we all know what I mean) are the defacto standard
way of storing data (** they are not the ONLY way**). Delphi's TDataset
etc components do a good job of providing an object oriented view of
that type of database. However, they do not model the problem domain
very well - there is often a big translation between that and the
database model. While they may be equivalent in many ways, the database
model is usually much more difficult to work with. This results in less
maintainable code.

So the aim of an OPF (which is not the same as "pure OO", BTW), is to
provide a mapping between objects which model the problem domain better,
and those which manage access to the database (which is normally a
different, less friendly model of the problem domain, and is much more
difficult to program with complex business logic. It is sometimes the
domain - no pun intended - of a specialist, and you want changes they
may make to affect small, well-defined areas of your application code).

Any suggestion that business logic should **always** be on the server is
plainly ridiculous. There are many occasions where that is either
undesirable or impossible (obvious example is when there is no server -
this type of app is commonplace). This has been pointed out many times
in this newsgroup.

In complex applications, many of us have found that we write code that
is easier to maintain and reuse by not hitting the database directly.
This is particularly the case when several programmers are involved, not
all of whom may have the necessary discipline (or skill) to use other
techniques :-)

Cheers,
Jim Cooper

____________________________________________

Jim Cooper      jcoo...@tabdee.ltd.uk
Tabdee Ltd      http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi with your Palm
____________________________________________