Any suggestions for separating data access, business logic and GUI in Delphi

Question

I want to separate data layer from business logic and business logic from GUI. Diving into web I stumbled upon a few resources but still unable to make my mind clear. Some people talk about patterns some others point various frameworks. My requirements are :

• manipulate data from rdbms (mysql mainly) CRUD operations
• dealing with id generation (should I use autoincrement or data engine supplied or pascal code generated)
• table relations may be logical (no referential integrity is used) or not
• need for ability to generate object relations from data model
• data must be converted to business object and business logic manipulated
• existing gui components or freeware ones should be used

What I need is :

• some guiding techniques / suggestions with basic sample code / application layout (such as units-classes-modules-directories) ... Being not an expert in OOP I get confused when I have to design the class hierarchy
• a simple framework with a tutorial
• or even your own daily code/framework/approach

Longer

Answer 1

Since you are using Delphi, make sure you look at DataModules. This is where you put your database access components and logic.

Put classes in plain "Unit" files.

Make the UI talk to these two for making things happen. You can use database access components direct on the form, but this is best done as a "display only" mode and using the datamodule to do the operations on the data. (You can do everything on the form for basic apps, but if you are wanting to modularise the app, keeping it apart is sensible).

Teriteria

Answer 2

One simple way to help enforce this kind of separation is to write unit tests for your business logic. Aside from the other (substantial) benefits, making code testable means it can't (intentionally or otherwise) be tightly coupled to the UI.

I try to (but don't always succeed) keep the details of the data layer separate by using ClientDataSets regardless of what's being used in the back end (usually DBExpress or DBISAM). I also try to write at least some integration tests to make sure the data layer works as expected (separate test database with known values).

With the business logic and data in place (even partly), the UI is much more straight forward. And maintainable.

Aquarist

Answer 3

Take a look at tiOPF

Oldie

Answer 4

Personally I use tiopf for the business model. Tiopf supplies the data access layer. The latest code from the repository includes a model-gui-mediator framework similar to MVC for displaying the model. This allows you to display your data using standard delphi components.

Tiopf also incudes a number of ID generators (guids, 32 bit and 64 bit integers etc).

If you are interested in tiopf, I suggest you start by looking at my overview. Then direct any questions to the newsgroups.

Playoff

Answer 5

Try your hands on open source InstantObjects and you will always want to use this for all kinds of database programming in Delphi.

In IO you will have to define the whole of data structure in its interface and then it will generate necessary code for you.

Just try it.

As for id Generation trust MySQL to generate an auto increment id for your. Don't spend time coding it.

Savoury

Answer 6

A method that I use, and works very well, is to attempt to take on different roles from your application, and then program as if you were in that role. For example, when you're working on the database back end, don't even think about the gui. Instead think about exposing classes and methods that just work with the data. If you make your own SDK that you will later consume, you will find that maintenance of this will be much easer.

Test based development is your friend. Get to know DUnit, and create small concise tests to exercise any non trivial code. Document the interfaces, and anything that is not apparent by looking at a screen full of code.

Draught

Answer 7

I would have a look at Model-View-Controller (which is an extension of the Observer / Observable Pattern). This means that the 'view' (i.e. the UI) only knows how to update the data, and then respond to data being updated. The Model (or Observable) knows how to manipulate data and tell Views that it has been updated. This means that you can replace the UI without having to change the data provider, and vice-versa.

Do a search on Google, as there are plenty of examples of this for Delphi (but not as much for Java / C#, etc.)

Obloquy