BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Design Recommendations

 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi Databases (Multi-Tier)
View previous topic :: View next topic  
Author Message
Dallas Goldswain [Retro-E
Guest





PostPosted: Wed Nov 10, 2004 9:41 am    Post subject: Design Recommendations Reply with quote



Hi All,

I am in the process of designing my first large distributed application by
myself, I would like to ask a few questions and get some advice. Using
Delphi 7 Enterprise

It will have about 10 concurrent users on our network.
Some Ideas on transaction handling and methods?

I am still not sure on which way to go with regards to DB technologies.
BDE, ADO etc Is the BDE that troublesome? I would like to use BDE as most of
Delphi is geared for it, but reading a few posts it seems like a
distribution nightmare.

I have looked at the Data Layer -> Business Rules -> Business Facade -> UI
Layer approach.
To my knowledge the Data Layer will have all the Datasets and Data Modules
etc and only pass to the Business Layer
Which is the best way of passing the data? xml streams? TCP?

From the Business layer to UI Layer should one use a "TCPDataset"? or XML
Stream? to a ClientDataSet or MemTable?

In the UI Layer, which has Forms and UI Process dll's, I have designed it so
that all interaction on the forms calls a function in the UI dll's to
eliminate code in the forms and to make maintenance easier, is this a good
way of doing things?


Thanks in Advance

--
-----
Regards
Dallas Goldswain
Retro-Eddy



Back to top
Bill Todd
Guest





PostPosted: Wed Nov 10, 2004 4:02 pm    Post subject: Re: Design Recommendations Reply with quote



Do not use the BDE. The BDE is no longer being developed and all of the
SQL Link drivers for database servers have been deprecated.

--
Bill (TeamB)
TeamB cannot answer questions received via email
Back to top
Wayne Niddery [TeamB]
Guest





PostPosted: Wed Nov 10, 2004 11:31 pm    Post subject: Re: Design Recommendations Reply with quote



Dallas Goldswain [Retro-Eddy] wrote:
Quote:

I am still not sure on which way to go with regards to DB
technologies. BDE, ADO etc Is the BDE that troublesome? I would like
to use BDE as most of Delphi is geared for it, but reading a few
posts it seems like a distribution nightmare.

As Bill has already advised, you should avoid the BDE. You don't say whether
you have a database in mind already. While there may only be a requirement
for 10 concurrent users presently, you should avoid "desktop" databases such
as Paradox (BDE), Access, FoxPro, etc. Use an SQL database server such as
InterBase, MS SQL, etc. This will give you much better reliabiliy, more
features you can take advantage of, and the ability to scale easily if that
should become a need in future. Your choice of database will affect your
choice of components, e.g. if InterBase, you can use IBX (InterBase
Express), if MSSQL then use ADO (dbGO), or you can use dbExpress in both
cases.

Quote:
I have looked at the Data Layer -> Business Rules -> Business Facade
-> UI Layer approach.
To my knowledge the Data Layer will have all the Datasets and Data
Modules etc and only pass to the Business Layer
Which is the best way of passing the data? xml streams? TCP?

From the Business layer to UI Layer should one use a "TCPDataset"? or
XML Stream? to a ClientDataSet or MemTable?

There are several different "middleware" products you can employ to handle
the transport of data between layers. There should be no need to invent your
own mechanism here. Delphi ships with DataSnap (nee MIDAS), and there are a
number of good 3rd party products as well.

Quote:
In the UI Layer, which has Forms and UI Process dll's, I have
designed it so that all interaction on the forms calls a function in
the UI dll's to eliminate code in the forms and to make maintenance
easier, is this a good way of doing things?

I'm not sure it is necessary to separate these into DLLs. That really only
makes sense if the functions there can be reused in more than one
application. Whether the code should be in the form or depends on what the
code is doing. If it is strictly managing visual display/user interaction,
then that is perfectly reasonable to be in the form. Interaction between
this and business rules definitely should be separated. The usual way to do
this is by creating classes that represent and implement the various rules.
The forms then make use of these classes.

You may get some ideas by browsing the posts in
borland.public.delphi.oodesign and the many links to articles and sites
you'll find referenced in posts there - the ideas advocated there are all
about the separation of UI/business rules/data access.

--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The legitimate powers of government extend to such acts only as are
injurious to others. But it does me no injury for my neighbor to say
there are twenty gods, or no God. It neither picks my pocket nor breaks
my leg." – Thomas Jefferson



Back to top
Dallas Goldswain [Retro-E
Guest





PostPosted: Thu Nov 11, 2004 6:08 am    Post subject: Re: Design Recommendations Reply with quote

Thanks, I will use dbGo for MSSQL

--
-----
Regards
Dallas Goldswain
Retro-Eddy


"Bill Todd" <no (AT) no (DOT) com> wrote

Quote:
Do not use the BDE. The BDE is no longer being developed and all of the
SQL Link drivers for database servers have been deprecated.

--
Bill (TeamB)
TeamB cannot answer questions received via email



Back to top
Dallas Goldswain [Retro-E
Guest





PostPosted: Thu Nov 11, 2004 6:11 am    Post subject: Re: Design Recommendations Reply with quote

Quote:
As Bill has already advised, you should avoid the BDE. You don't say
whether you have a database in mind already. While there may only be a
requirement for 10 concurrent users presently, you should avoid "desktop"
databases such as Paradox (BDE), Access, FoxPro, etc. Use an SQL database
server such as InterBase, MS SQL, etc. This will give you much better
reliabiliy, more features you can take advantage of, and the ability to
scale easily if that should become a need in future. Your choice of
database will affect your choice of components, e.g. if InterBase, you can
use IBX (InterBase Express), if MSSQL then use ADO (dbGO), or you can use
dbExpress in both cases.
I have decided to use MSSQL 2000, thanks for the tip, been out of the loop


Quote:
There are several different "middleware" products you can employ to handle
the transport of data between layers. There should be no need to invent
your own mechanism here. Delphi ships with DataSnap (nee MIDAS), and there
are a number of good 3rd party products as well.
Looking at datasnap, also trying out midware and ics by F Piette



Quote:
I'm not sure it is necessary to separate these into DLLs. That really only
makes sense if the functions there can be reused in more than one
application. Whether the code should be in the form or depends on what the
code is doing. If it is strictly managing visual display/user interaction,
then that is perfectly reasonable to be in the form. Interaction between
this and business rules definitely should be separated. The usual way to
do this is by creating classes that represent and implement the various
rules. The forms then make use of these classes.
Thanks great idea, will try this route, much easier

Thanks Wayne for all the tips




Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi Databases (Multi-Tier) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.