[Mono-list] Application Architecture

Doug Pomerenke djp@visi.com
30 Nov 2003 22:28:43 -0600


On Sat, 2003-11-29 at 16:50, Timothy Parez wrote:
> Hello,
>  
> I have a question about application architecture and I figured this is
> as good a place as any to ask my question.
> Currently I have a small database (29 Tables, 149 Columns in total)
> and now I want to write code to use the database.
>  
> The idea is to write a class library to access the code, so that I'm
> not bound to a specific user interface,
> I guess this is a normal DAL component then. Now I've read some books
> on ADO.NET, and though all of them
> give a very good insight on the inner workings and usage of ADO.NET
> they do not offer much information
> about best practices or real life application design. They just throw
> some building blocks at the reader,
> show off some small applications and that's it. So I'm asking your
> advice on how I should develop my DAL.
>  
> Where do I start, what are the things I need to keep in mind, etc...
>  
> I would also like to know about personal experience you may have had
> on the subject, problems you encountered and so on.
> One thing I don't need is a link to another webpage explaining to me
> how to create a provider independant dal component,
> I need advice on real life application development, not an ADO.NET
> tutorial :-)
>  
>  
> I know this is a very 'global' question, and that there is no strait
> answer to my problem,
> but that's why I would like to start this discussion, perhaps I can
> learn from your own experiences
>  
>  
>  
> Thank you.
>  
>  
> Note: This message has been posted on the gotmono.com forum aswell.
>       (http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=PROJECT;action=display;num=1070146165;start=0)

I'm working through these issues right now. I am making a client/server
desktop app. Strictly single user, no web stuff. I want it to run on
Linux, Windows, Mac, etc, as well as have the option to chose a
different database. Currently I'm using Firebird, which is overkill for
the single user requirement. SQLite sounds like a better choice.

>From my experience building client/server desktop apps using MS VB and
Access, a major source of design regret is having dependencies between
the source code files which contain your business logic and the files
which contain references to the GUI components, (widgets), and their
event handlers. An even greater sin is to have dependencies between the
source code files containing the GUI and the database access. 

Another poor design is implementing unrelated business functions, (use
cases), in the same source code files, especially the business logic
part. It may seem that listing account information and editing that
information are the same, but inevitably what will happen, after several
months of coding, debugging and testing, your boss will come to you and
say that they want a separate application for certain users who are not
allowed to edit the account information, "could you just reuse this
program and make one that only lists the account info, should be quick
and easy". Now, after cutting, pasting, hacking, and leaving some dead
code and unused variables, you have two source code branches to
maintain.

How I plan to avoid these pitfalls is to design the app in three layers.
The middle layer contains the business logic that will be the same
regardless of UI or database. It consists of classes for business
objects, and base classes, I call them adapters, that have the methods
used by the classes in the middle layer to interact with objects in the
UI and database layers. I subclass these adapter classes in order to
implement code that is dependent on the GUI toolkit and database. The
source code for these sub classes is in different files than the code
for the base classes. I also use a delegate in the database adapter base
class, and a callback, to fill the business objects from the database
adapters. The startup class has subclasses for each supported GUI
toolkit. An instance of this subclass is instantiated in Main(). This
should be the only class in the middle layer that has a references to
classes in the other two layers. And these are only a couple of lines of
code.

Currently I'm developing on Linux using Eclipse for the IDE and make to
do the build. All the files to be compiled are listed in the make file. 
Hope this is useful.