Databinding - Best Practice (object-oriented)

[james]

Alfredo,

So explain this to me. Suppose your Customer orders a product from you, and
you have a business rule that states that if the order is greater than a
certain $ amount, you need to obtain additional information from the
customer such as a credit card number, so the applicaiton is to pop up a
panel for the ordering person to fill in. Now if the business logic is
stored in the DB how does the database pop up this panel. This is business
logic. If your solution is to throw an exception on the database server and
to force the app to read that exception to know what to do, then, you can
only do that by saving the incomplete data or calling a specialized stored
procedure. If you have to build your app entirely around calling stored
procedures then your app becomes hopelessly tied to your database. In our
applicaiotns we can easily swap out the database because the app doesn't
care or require custom SQL written in the databse. Ever tried to re-write
thousands of stored procs / triggers for Oracle ? Unfortunatley SQL Server
/ Oracle ... do not have identical implementations of SQL 92


JIM

 

[Grant Frisken]

On Tue, 8 Jun 2004 08:52:37 +1000, "Grant Frisken"


No you can not. What I mean is that tables are not "first class
citizens" and arrays are.

What I mean is something like this:

var a relation { a integer, b integer } key { a };

a := relation { tuple { a 1, b 2 }, tuple { a 2, b 1 } };

var b relation { a integer } key { a };

b := relation { tuple { a 1 }, tuple { a 3 } };

b := (a join b) { a };

With ADO.NET you can not do anything of this.

You can do all of this - but it takes a lot more code.

This is not true. The Relational Model is completely independent of
the inheritance. There are relational languages with inheritance and
polymorphism, and all of them have encapsulation.

Do any of the major RDMS vendors currently support these features and have
an interface into .NET for this?

I can't agree more. For me ADO.NET is simply unusable for complex
applications.

I use it for Pocket PC apps only because it does not worth to create a
replacement for very simple applications.


But IMO that agreement is based on the ignorance of what The
Relational Model really is. The Relational Model is not SQL. SQL was a
quick and dirty experiment of the 70's that never should be released.

Perhaps - but it is the now widely adopted standard. You will find it
difficult to persuade developers to ditch the database independance this
gives them (although far from complete or perfect) and bind themselves
tightly to one vendors view of the world. I think this is part of the
problem that OO databases have had in getting developers to adopt them.

You can have single and multiple inheritance with The Relational
Model, and even you have inheritance in SQL 3.

Not sure what you mean by a domain.

A data type. What SQL domains should be but they are not.

I suppose you know what SQL domains are:

CREATE DOMAIN name [AS] data_type
[ DEFAULT expression ]
[ constraint [ ... ] ]

I have to plead ignorance here. I am by no means a DBMS guru - but I was
unable to find any reference to this in MSDN - so I am assuming that SQL
Server does not support them. From the documentation I could find on
sql.org it looks like this is restricted to defining primitive datatypes
with constraints and defaults.

To claim that this is the only possible mapping to classes seems to me to be
like designing a language which only supported classes derived from
primitive types.

Class and domains are the same.


No, it is basic common sense. The most common meaning of class is data
type (class may mean many things like most OO terms), and database
domains are data types. They are the same.

But OO classes do not equal primitive types. In fact in general an OO class
equals type consisting of member variables and member functions

On the other hand tables are variables and it is evident that to
confuse a variable with a type is a monstruous blunder.

But table definititions or schemas are not variables and could easily be
equated with classes (although one to one mappings are probably a mistake as
we have discussed)

User interface logic is application development, but business logic is
data management.

Business logic are the data integrity and data derivation rules.
Business logic and databases are indissoluble. Business logic is ALL
in database design.

Well this depends on your definition of business logic. I'd be more than
happy to use the database to enforce as much business logic and constraints
as possible. However in my experience there are some things that I would
classify as busines logic that you can't do in a RDMS.

Regards
Grant

 

[Alfredo Novoa]

You can do all of this - but it takes a lot more code.

It is like to say that you can do all of this is assembler. What I
meant is that you can not work with tables as you can work with
scalars or arrays.

Do any of the major RDMS vendors currently support these features and have
an interface into .NET for this?

SQL Server Yukon.

Oracle support these features but I don't know if you have an
interface into .NET for that.

Perhaps - but it is the now widely adopted standard. You will find it
difficult to persuade developers to ditch the database independance this
gives them (although far from complete or perfect) and bind themselves
tightly to one vendors view of the world.

IMO DBMS independance is a myth. I have seen projects which changed
the application language 5 or 6 times and the DBMS was always the
same.

BTW SQL Server is not very faithful to the ISO standards.

I think this is part of the
problem that OO databases have had in getting developers to adopt them.

I don't think it is the problem of OO databases. If you try to use an
OO DBMS you will realize soon that you need a lot more code.

CREATE DOMAIN name [AS] data_type
[ DEFAULT expression ]
[ constraint [ ... ] ]

I have to plead ignorance here. I am by no means a DBMS guru - but I was
unable to find any reference to this in MSDN - so I am assuming that SQL
Server does not support them.

No, it does not support the standard SQL syntax. The equivalent in
Transact SQL is: sp_addtype

From the documentation I could find on
sql.org it looks like this is restricted to defining primitive datatypes
with constraints and defaults.

It was in SQL 92, but not in the modern versions.

But few products follow the standards.

To claim that this is the only possible mapping to classes seems to me to be

The only correct mapping. But we need decent user defined type support
to do a good mapping.

With SQL Server Yukon we don't need to map anything because you can
use the same classes (the same code) in the DBMS and in the
applications.

like designing a language which only supported classes derived from
primitive types.

It was a problem in the past. That's why many people did the mistake
of identifying classes with tables. But now they have not excuse. All
major DBMSs support classes and not only primitive types.

But OO classes do not equal primitive types. In fact in general an OO class
equals type consisting of member variables and member functions

I think this was already clarified.

But table definititions or schemas are not variables and could easily be
equated with classes

No, table definitions are variable definitions and they can not be
equated to type definitions (other of the meanings of class).

For instance:

Create table X (A Integer, Primary Key(A));

is the equivalent of;

type
T = table (A Integer, Primary Key(A));

var
X: T;

But the SQL syntax do both steps together. You are creating a type and
a variable at the same time.

With SQL you can not define relational types. You can generate them
only. The SQL's "CREATE TABLE" construct is called a "type generator"
in the jargon.

The closest thing in OO languages are the array type generators.

var X: array[1..100] of integer;

Here you are generating a type and creating a variable at the same
time.

On the other hand if you create a class:

class Customer
{
public int ID;
public string Name;
}

You are creating a type only. You can not insert or delete anything on
the class.

You have to create variables and pointer based lists, and then you
have returned to the prehistory of the data management.

Well this depends on your definition of business logic.

What is yours?

I agree more or less with this:

http://www.awprofessional.com/articles/article.asp?p=98832&seqNum=2

And I agree a lot with this:

http://www.versata-deutschland.de/p...ei_der_Software_Entwicklung_by_Chris_Date.pdf
http://itmanagement.earthweb.com/entdev/article.php/622991

I'd be more than
happy to use the database to enforce as much business logic and constraints
as possible. However in my experience there are some things that I would
classify as busines logic that you can't do in a RDMS.

I agree with you if you change RDBMS by SQL DBMS. This is one of the
reasons because SQL DBMSs are not RDBMSs

It is a big problem, and what we need is better DBMSs that can enforce
any kind of business rule declaratively. But the industry is not
moving in that direction.

For instance Dataphor is very good on this, and most of the
theoretically updateable views are updateable.

Oracle is inferior but it can implement many business rules
declaratively.

Unfortunately SQL Server is even very inferior.

On the other hand the OO community is doing all the contrary, to
implement ALL the business rules in the applications like our fathers
did on the 50's and the 60's.

OOAD is a clear technological regression.


Regards
Alfredo

 

[Alfredo Novoa]

Alfredo,

So explain this to me. Suppose your Customer orders a product from you, and
you have a business rule that states that if the order is greater than a
certain $ amount, you need to obtain additional information from the
customer such as a credit card number, so the applicaiton is to pop up a
panel for the ordering person to fill in.

The business rule is not very well specified.

It should be: if the order is greater than a certain $ amount it can't
be stored without aditional information.

The pop-up panel is not a business rule it is a presentation rule.

Now if the business logic is
stored in the DB how does the database pop up this panel.

You are confusing business rules with presentation rules.

The business rules must be enforced on the database and applications
must not be able to store big orders without aditional information
although they were flawed or manipulated.

On the other hand the presentaion rules must be enforced by the
application although they can be stored in the DBMS too.

If your solution is to throw an exception on the database server and

Only if the application violates the rule.

If you have to build your app entirely around calling stored
procedures then your app becomes hopelessly tied to your database.

Stored procedures are the worst way to enforce business rules.
Business rules should be enforced declaratively always it is possible,
and most times it is possible.

You can see Oracle's "check" statements.

In our
applicaiotns we can easily swap out the database because the app doesn't
care or require custom SQL written in the databse.

In our systems we can easily swap out the applications and the
application language because the most part of the logic is in the
database

Application languages and user interface frameworks are a lot more
volatile than DBMS's, and you have a lot more to choose, specially if
you work on different platforms.

Declarative business rules are very concise and very portable. Stored
procedures should be the last resource.


Regards
Alfredo

 

[Alfredo Novoa]

On Wed, 9 Jun 2004 09:20:39 +1000, "Grant Frisken"

Another interesting article about Business Rules:

http://www.dulcian.com/ODTUG 2003 B...rs_Business Rules Theory & Implementation.htm

 

[james]

What I am saying is that the business rule is if some value is > some amount
do some special thing. How can that be stored in the database and yet tell
the GUI to respond ?


JIM

 

[Alfredo Novoa]

What I am saying is that the business rule is if some value is > some amount
do some special thing.

With a triggered procedure. For instance the DBMS can invoke an
application which sends an email if some value > some amount.

BTW it is a bad practice to update tables with triggers.

How can that be stored in the database and yet tell
the GUI to respond ?

You are mixing a business rule and a presentation rule, they are
different things. Business rules are independent to the GUIs.

There are many ways to implement the presentation rule of your
example.

Regards
Alfredo

 

[Roman Pokrovskij]

I'm also advising you (like Fowler in Enterprise Patterns) to use the OO

approach together with an ORM with data binding support *if* you have complex
business logic.

If you will say, that because of this our concrete .NET Windows Forms data
binding API is the preferred way -- it would be an absolutely crazy mind.



..NET Windows Forms data binding can't be used in the project with the
complex logic (at least alone, without any object persistence and query
engines). Because of the complex logic require complex query language.

 

[Roman Pokrovskij]

Basically Microsoft recommends to have 4 layers (presentation,

business component, data access component, database). The classes
should be stored in the business component but not everything should
be an object.

What are you talking about? Who is interested in this theory here? Be
closely to ADO and Windows Forms! Take a look at TreeView for example. This
class from presentation layer does not work with the natural "tree model"
abstraction which you will use in your business logic. The same is true
about DataGrid and "Table model" abstraction. Compare with Java Swing.
Therefore, if we are talking about Microsoft, ADO and Windows Forms we
should admit that successful applications development in this environment
should be "data-centric" with "one and half" layers. It is not bad, but it
is our reality.