Distributted Application

[trungluu]

Hi,

Do you know how to build a Distributted Application in 3 tiers? Do you have an example about this? Could you please tell me how to code the business entity and data entity? what is the relationship each other? I should build one class for one table or not? If I build a class for a table how to I join the tables? do you have a clear example about the relationship between business logic class and data class? How to seperate them? How to a business entity contact with a Data entity?

Thanks in advance,

Trung Luu

[Edneeis]

Here is the general break down usually in a 3 tier app the User Interface (all the forms and the app itself) are 1 layer, a series of classes make up the business layer (it doesn't matter if it is 1 class per table or not, just whatever fits best for the situation) and then last layer is the database itself (hopefully SQL but Access works to or whatever else you want to use). The idea is that seperating the application into these parts makes it more managable. Lets say you want to move the app from Access to SQL then you may just need to change the database itself or at most rework some of the biz classes and the DB, but the since none of the data access code is in the app itself you don't need to redistribute that part or rewrite it. Lets say you want to make a web version of your app then you can just reuse the biz rule classes and DB and write an asp/web face for it and you're done. I think a lot of times we make this more complicated then it needs to be, just where ever you would normally connect directly to data you will now connect to a class(es) that will get the data thmeselves. Other than that you've probably done most of it before. Of course it can get much more complex than that but that is the gist of it.

[lon]

what you describe sounds more like a 4-tier system where you have:
Presentation - > Business objects -> Data objects - > Database

I know some companies design their data objects to simply return a recordset of the data that is required and then for write back simply run a store procedure with the parameters. The advantage of doing it in a four tier system is that if the db changes you only have to change the data objects.....etc.. Depending on what your system is going todo you might even want to pass a recordset all the way back to the presentation layer (although this destroys the idea of OO programming IMHO)..

You want to avoid passing objects between layers.. I have found that to pass a customers object for example to your data layer to be filled up with data and then passed back can be very slow..

You might also want to look at passing data as XML between your layers.. This is useful if the system is truely distributed across systems because it avoids the system having to serialize the objects (because the XML string is already serialized).. If you are using SQL server (not sure which versions do this), but you can use the FOR XML keyword to return the data from SQL server in XML format.. You will however need to return this into an ADO stream object.. If you are transfering alot of records with alot of fields in them then this can also be quite slow..


Basicaly have your data objects reading and saving data... Have your Business Objects represent your entitys customers, invoices..etc. and have them do all the processing.. and your presentation layer simply using the business objects to display the data with virtualy no functional data processing..

hope that helps a bit..

rgds
chris

[lon]

Hi
me again.
one more thing... when you talk about linking tables... You still need your RDB designed and linked properly with all the keys..etc.. The backend database can still handle all the relational stuff...

have fun...