Howto Programming Three-tiered Object Oriented?

[RedLion]

Hello,

Everybody is speaking about Object Oriented and Three-tiered applications. And everybody can speak about it realy nice, but when you come to the reality everything is on an other way, the question become how to bring the theory in practice?

On the bottom we've got the Database, and the layer above we got the business logic and the last layer is the interface.

[business logic]
A normal object is a Person. It has a name and adress as the properties. On that properties you can let methods work. GetName(), SetName() and so on.....

But now we've got a database with 1 million records. What to do now?
Read all records out a Database and define an array of 1 million person objects? Or should you say I define one class only with methods, and my properties are still in the database? When I need some data I use a sql-statement and put the selected data in a Cursor which gives the Cursor to the Interface layer, and the Interface layer fills the grid with that information?

This is a thing where object oriented sounds nice but how to implement it in the real world?

Thanks,

Charl

 

[foxdev]

Here's a real-world example:

There are a set of forms for data entry. The application is used by several different companies, each with their own special rules. Therefore, we want to isolate the user interaction and "always-on" validations, such as entering invalid dates, from those that are customer specific.

We also want the ability to support different data sources.

So, we end up with forms based on various form classes (such as DataEntryForm). When you hit the Save button, the form calls one or more appropriate non-visual (Custom) objects which do the validation. These NVOs can be swapped out easily to accomodate different companies, and in any case modifications to business rules are separated from the user interface.

Finally, both the form and, if needed, the business objects use an SQL object for most of the data interface; if we need to use a different data source, we simply change the SQL object.

Robert Bradley

http://www.foxdev.com/

 

[RedLion]

Hi Robert,

How does the SQL-object looks(array of objects filling with SCATTER.. NAME.. ?

And at what kind of way is the data past to the interface, in a cursor or does it use the methods of the objects created in the business layer to fill something like a textbox?

Thanks,

Charl

 

[foxdev]

The SQL objects I've created and/or used in the past have properties such as:

cSQLCommand
nHandle
cServerType
cErrorMessage
nError

and methods:

Connect
Execute

To get fancy and make a very flexible one, you'd set the cServerType to a value that dictates what special handling you might incorporate; but this is purely optional, and only if you want to support multiple data systems in one object.

Here's an example of how it would work:

[tt]oSQL = CreateObject("SQL&quot
* -- UID/PW could be properties instead of parameters
if not oSQL.Connect("MyUserID", "MyPassword&quot
return .F.
endif
oSQL.cSQLCommand = "select * from MyTable"
oSQL.Execute()
* -- Execute method sets nError and cErrorMessage
if oSQL.nError <> 0
MessageBox(oSQL.cErrorMessage)
endif[/tt]


Robert Bradley

http://www.foxdev.com/

 

[jonscott8]

Robert,

I think Charl is asking how the Client accesses/interfaces with the data that is queried in the middle tier. Because in your example above, if oSQL is a COM object responsible for the middle tier, the cursor created with &quot;select * from mytable&quot; can not be returned to the client tier.

Charl,

FWIW, IMO, using OOP for data access in n-tier architecture is too much overhead on the client (unless you are using ADO). It forces the client to make repetitive calls to the data tier to retrieve ALL the properties(fields returned in the query) of ALL the objects(records returned in the query). And as you probably know, it is good practice to minimize COM object calls because they are (for lack of a better word) slow.

I would highly recommend you read the following article by Robert Green:

Building Three-Tier Client/Server Applications with Visual FoxPro

http://msdn.microsoft.com/library/techart/msdn_bko01.htm

It is a little old (almost 4 years), but it is definitely a great starting point for any n-tier beginner. FWIW, it passes the data between the tiers in delimited-text format. XML has become a popular alternative to delimited-text, especially with the emergence of the SOAP protocol. Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[TomasDill]

You can also read the Wednesday Night Lectures at the fox.wikis.com, there are some nice lectures there on n-tire technology, COM objects etc etc.


Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[foxdev]

Jon, you're correct in the point that I did not specifically say, but I did say that they were VFP Custom objects; the SQL class in my example is just that: a VFP class. As such, it returns cursors (or updatable views, if you want it to) to the calling program.

So, in response to his question &quot;How does the SQL-object looks&quot;, I think I gave a pretty good overview. He would work with the resulting cursor the way you'd work with any other VFP cursor.

Simply being a &quot;middle-tier&quot; OOPish object does not make it an ADO object, but my apologies for not making it more clear in my explanation.

Robert Bradley

http://www.foxdev.com/

 

[jonscott8]

Robert,

it returns cursors (or updatable views, if you want it to) to the calling program

If oSQL is an OLE/COM Server, this is not possible. If the cursor is created in the middle tier, the client can not see the cursor. VFP cursors can not be passed between the tiers, and thats why the client can be developed in VFP,VB, or Java and still interface with the middle tier.

Now, if this is a client/server (2-tier) architecture, then you are correct. The client will see the cursor returned by oSQL.Execute() because they reside in the same tier.

He would work with the resulting cursor the way you'd work with any other VFP cursor.

Then this must be a 2-tier architecture. Also, this is NOT OOP data access. VFP Cursors are not Objects. OOP data access would be similar to this:

(In the Middle Tier)
PROCEDURE oSQL.GetPerson
LPARAMETERS tcName

lcSQL='SELECT * FROM PERSON WHERE NAME==&quot;'+tcName+'&quot;'
SQLEXEC(THIS.inConn,lcSQL,'MyCursor')
lnRows=RECCOUNT('MyCursor')
THIS.AddProperty('oPerson['+TRANS(lnRows)+']'))

FOR X = 1 TO lnRows
lnRec=RECNO('MyCursor')
SCATTER NAME THIS.oPerson(lnRec)
SKIP
ENDFOR

RETURN lnRows
ENDPROC

(In the Client Tier)
lnResult = oSQL.GetPerson('BRADLEY')
FOR X = 1 TO lnResult
USE MyDummyCursor
APPEND BLANK
MyDummyCursor.Name = oSQL.oPerson(X).Name
ENDFOR

Read all records out a Database and define an array of 1 million person objects?

Yes, if you are wanting OOP data access, which I dont recommend unless you are using ADO.

put the selected data in a Cursor which gives the Cursor to the Interface layer

You cant return a VFP cursor or else you would be forcing the client app to be developed in VFP so that if could interpret VFP cursors. Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[foxdev]

VFP cursors can not be passed between the tiers

Strongly disagree. You are saying that by definition a middle-tier object must be COM; I am saying no, that the design of separating your user interface from your business rules which itself is seperated from the data store is the traditional definiting of 3-tier architecture. This definition does not require that each of the three pieces exist as DLLs.

But I'll give you this: the data access mechanism being separate does not make it OOP, and that both native DBFs and ODBC cursors are not OOPy.

Robert Bradley

http://www.foxdev.com/

 

[jonscott8]

You are saying that by definition a middle-tier object must be COM; I am saying no, that the design of separating your user interface from your business rules which itself is seperated from the data store is the traditional definiting of 3-tier architecture.

I agree that seperating the 3 components constitutes a logical 3-tier architecture. But the implementation you are describing is a physical 2-tier fat client architecture, where the presentation logic and business rules run on the client and are only seperated in the code base. And, by definition if both the user interface application and the business object run at the client, it is still a two-tier implementation. Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[TomasDill]

Jon, I agee with Robert and disagree with you. We have 3-tire application that runs business rules at client side, but they're easy replacable like a business object in 3-tire application. How this implemented? See following.
There are table that stores each field of each table in database. In this table we have memo fields that allows to define some validation and access (compare to When event of textbox). Than each control of form have special base class with similar functionality that reads this code from database and runs it in When and Valid events. User (with admin rights) can change validation rules on the fly and they apply near immediately without restarting of client application and any fail in the application working. Finally, there are the same approach for data saving.
Is it not a third tire - validation rules? ) It is completely separated from client application, located separately and easy replacable.

Finally, read

http://www.n-tire.com

(not sure I remember it correctly). There is entire concept of this theory described. The main thing you shoud aware about there is that n-tire technology is not PHYSYCAL dividing of application, but LOGICAL.

Hope this helped to make things clear.



Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[BlindPete]

Whoa! What an education. I love it when your pro's disagree. I learn so much more that way!!!!!!!!!!

Pete
blindpete@mail.com

What your mother told you is true! You will go blind! (from moonshine anyway)

 

[TomasDill]

Sorry, guys, correct link for free articles about n-tire concepts is:

http://www.n-tier.com/WhatIsN-Tier.html

Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[foxdev]

Well, Jon, at least its clear where we disagree:

Jon: If the business logic (business rules) code actually runs on the client, regardless of its being separate, encapsulated objects, it is two-tier.

Robert: If the business logic (business rules) code exists as separate, encapsulated set objects, then it (along with the presentation layer and the data layer) can be called a three-tier system, regardless of where the business object code runs.

Did I state your position correctly, Jon?

If so, then by your definition the business layer must run on a third machine. IOW, one machine is the user interface client, another is the data server, and - because the business layer code cannot run on the same machine as the other two layers (my assumption of the logical extension of your position), it must run on a third machine (or set of machines).

Keep in mind that a business object developed in Delphi and stored as a DLL that is invoked by VFP will still run on the local machine (unless DCOM, but let's not complicate things), even though it is an external process.

Robert Bradley

http://www.foxdev.com/

 

[RedLion]

First of all I want to thank everybody answering my question.
I’ve been busy with some other things this weekend, and now I’m back I see that I’ve started a long discussion.

My opinion:
If something is a three-tiered application depends on the way how it’s programmed, not how it is in action (when the program is working). It’s how it is logical build up.
The main reason for building three-tiered applications is the flexibility, when programming the interface you have not to think about mutation-rules (things where you’ve to think about for changing a record in the database) and ease of maintenance. The fact that it has to be recompiled is mostly not the problem in order to switch components, interfaces or data sources, compiling takes just a couple of minutes. So compiling all the tiers into one EXE doesn’t say it’s a two-tiered application in stead of three-tiered.
(I just said my opinion, and after all I’m not an expert, more a rookie, so I like all the discussions from the profs, I’m learning!!!!!!!!)

The reason of my post was that I’m building a application for a small company with 4 clients, and one of the clients has also to serve as server for the database. And my question was how to get the data from the database to the interface on a request by the interface layer, by just putting the question to the business layer?

After reading the things posted as reaction on my question Robert came up with COM-object, and I still didn’t knew how to exchange the data (not to you Robert, but my own stupidity) And than Jon Hawkins came with a link to a Microsoft-page, and there they explained things a bit.

So I will explain how I’ve thought of doing things, so correct and improve me on things.
The business layer and data layer communicate through SQL. In the business layer I make an object in plural and one in singular. Plural for communication from business to interface, and all the mutations that have to made to the data will be created as a singular object.

Example:
Plural:
Companies
GetCompanies (will fill a public cursor which is a property of the Plural class)

When there are some mutation made in for example the grid in the interface, the interface will create an object, with properties the data from one company, the one that has to be mutated. And than calling the method doUpdate which will update the database through SQL.

What do you guys think of the idea? Did I do something stupid, or can it be done on a better way?

Thanks,
Charl

 

[jonscott8]

I prefer not to get into the &quot;Is it/Is it not&quot; arguments, ie(&quot;Is it OOP/Is it not&quot;,&quot;Is it N-Tier/Is it not&quot. Therefore, I'll try and make this my final argument in regards to this thread.

Take 10 minutes and read the following white paper:

Three-Tier Application Development

http://msdn.microsoft.com/library/techart/designeff_three.htm

Under the &quot;Two-tier implementation (fat client)&quot; section:
If both the user interface application and the business object run at the client, it is still a physical two-tier implementation. Separating the code, however, makes it easy to move to the physical three-tier implementation...

Vlad,

A few quotes of

http://www.n-tier.com

from the &quot;3-tier architecture&quot; section:

3. A middle-tier component, which allows users to share and control business logic by isolating it from the actual application

When business logic changes are required, only the server has to be updated. In two-tier architectures, each client must be modified when logic changes.

The application layer can be written in standard third or fourth generation languages, such as Java, C or COBOL,...

A couple questions for the implementation above:

1. When a business rule changes, do you have to replace the .exe on every client workstation?

Yes, because the business rules are built into the application.

2. Can the application be written in Java,C, or VB and still interface with the &quot;middle-tier&quot;?

No, the developer is forced to code the application in the same language as the &quot;middle-tier&quot; was developed with. Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[foxdev]

2. Can the application be written in Java,C, or VB and still interface with the &quot;middle-tier&quot;?
No, the developer is forced to code the application in the same language as the &quot;middle-tier&quot; was developed with.

You had me right up to this point. The answer is &quot;yes&quot;, because you could write the business objects in VB, saved as a DLL, and instantiated by VFP, but it still runs on the client (again, discounting DCOM for the sake of simplicity).

Robert Bradley

http://www.foxdev.com/

 

[jonscott8]

Robert,

I think my inconsistent use of the word &quot;Client&quot; might be what is causing the confusion. I should have been more specific and said &quot;Client-tier&quot; and &quot;Client workstation&quot;. My apologies.

because you could write the business objects in VB, saved as a DLL, and instantiated by VFP

If I'm not mistaken, this brings back Charl's question, how does the middle tier pass data back to the client tier? Jon Hawkins
jonscott8@yahoo.com

The World Is Headed For Mutiny,
When All We Want Is Unity. - Creed

 

[TomasDill]

Jon, it seems you did not understood the idea in our application. See answers:

1. When a business rule changes, do you have to replace the .exe on every client workstation?

Yes, because the business rules are built into the application.

No. Because business rules stored in the database on some server and just downloaded by client, compiled and ran. EXE just contains code to do all this, but it DOES NOT contains business rules, all of them stored on the server. VFP 6 SP3 allows to compile any VFP prg in run-time without any penalties by using 'COMPILE' command (SET PROCEDURE will not work in run-time until you compile PRG file).

2. Can the application be written in Java,C, or VB and still interface with the &quot;middle-tier&quot;?

No, the developer is forced to code the application in the same language as the &quot;middle-tier&quot; was developed with.


I think (and always thought) that all three tires might use VFP. No matter which language used for middle tire, application should have the ability to run (call) it. With the same success instead of 'COMPILE' command and call of native VFP function I can use some other tools, like binary code, special script code (that is the most preferable for users to write business rules by power users), etc.
Anyway, language is not requirement, and many people agree with that (see lecture of Craig Bernston on n-tire). The requirement in n-tire technology - each client should 'know' how to run these business rules, should 'know' how to communicate with tires. How tire is implemented - does not matters at all.



Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs

 

[TomasDill]

Jon, it seems you did not understood the idea in our application. See answers:

1. When a business rule changes, do you have to replace the .exe on every client workstation?

Yes, because the business rules are built into the application.

No. Because business rules stored in the database on some server and just downloaded by client, compiled and ran. EXE just contains code to do all this, but it DOES NOT contains business rules, all of them stored on the server. VFP 6 SP3 allows to compile any VFP prg in run-time without any penalties by using 'COMPILE' command (SET PROCEDURE will not work in run-time until you compile PRG file).

2. Can the application be written in Java,C, or VB and still interface with the &quot;middle-tier&quot;?

No, the developer is forced to code the application in the same language as the &quot;middle-tier&quot; was developed with.


I think (and always thought) that all three tires might use VFP. No matter which language used for middle tire, application should have the ability to run (call) it. With the same success instead of 'COMPILE' command and call of native VFP function I can use some other tools, like binary code, special script code (that is the most preferable for users to write business rules by power users), etc.
Anyway, language is not requirement, and many people agree with that (see lecture of Craig Bernston on n-tire). The requirement in n-tire technology - each client should 'know' how to run these business rules, should 'know' how to communicate with tires. How tire is implemented - does not matters at all.
Business data in our application - all VFP data, so runs quickly and require noting additional for communication. This does not prevents, however, to use these data in another client, for example, VFP COM object that will be interface for these business rules for other clients to run them.


Vlad Grynchyshyn
vgryn@softserve.lviv.ua

http://www.softserve.lviv.ua

The professional level of programmer could be determined by level of stupidity of his/her bugs