The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Where should be Control Logic...

Hi all,

in 3- tier systems what is the best place for control logic.
let me give a simple example,

I have a personID that must be 11 char long and must ve start with P.

in GUI I have txtPersonID box.
in Object base I have Person class, Person.PersonID string and Person.Save, Person.Load etcc...
and in DB I have PERSON table and PersonID as column.

Assume users wants an error indicating that "PersonID is not valid". And Wants some GUI functionality for it such as focusing, or that stupid red balloons... So, We decided Control Logic must be in GUI.

But one of the noob developer in company want to use That Person Class, he don't know any knowledge about Person class he just need to create a Person and Save it using Person.Save... So, we need a Control Logic in our class.

After somedays we get a new project and we must import some data from another system. So our DBA write a database script to get their data and import them into our system. And that time we need a Control Logic in DB, because noob DBA don't have any knowledge about Person class, actually he saw all PersonID's have P in beginning and they are all 11 char long, but he didn't realize how it is critical for our system :/

So, I really wonder where should it be.
I am Noobi Send private email
Friday, December 08, 2006
 
 
Standard wisdom is to put logic in the object tier.

'One-time' events like database imports need to be carefully planned to ensure they don't violate any business rules.
Mike S Send private email
Friday, December 08, 2006
 
 
Well I think that you are combining multiple requirements and calling them all "control logic". Based on Microsoft architecture guidelines I like to break applications into 4 layers instead of the traditional 3.

User Interface Layer (GUI)
User Process Layer (state machine)
Business Layer (rules)
Data Layer (data objects and database interfacing)

So in the case of simple validation of data, it should be triggered by common code in the User Process Layer (the state machine), use validation rules found in the Business Layer, and show results in the User Interface Layer (GUI).

The fact that one user  might want a red box while another might want you to play an annoying raspberry sound when an error occurs are all details that should reside in the GUI and not be dependant upon the actual business rules used for validation. Likewise, the act of triggering validation is very common and should be handled by the User Process Layer in the form of a state machine instead of being triggered directly from the UI. In this case the UI notifies that a save command has been triggered and the User Process Layer runs the common logic to trigger validation. Note that neither of these layers really need to concern themselves with what the validation rules really are which allows them to be changed at will.

As for the database side of things, that is always a tricky. The problem of having some DBA mucking around in the database is a common one. But instead of moving/placing control logic there you should push these individuals to interface to the data through the application somehow rather than going directly after the data themselves.

That's just my two cents.
Turtle Rustler
Friday, December 08, 2006
 
 
"As for the database side of things, that is always a tricky. The problem of having some DBA mucking around in the database is a common one. But instead of moving/placing control logic there you should push these individuals to interface to the data through the application somehow rather than going directly after the data themselves."

God help you all.

How about this for a wizard idea. You have a constraint (heard of those?) so that only the values you want to allow can actually be entered into a field in a table. Would that help atall?

Perhaps not. Or you could have some validation in any form that enters/deletes/updates PersonID. Infact that's probably the best place to put all your validation, in the user interface. Yes, I've changed my mind, put it there.
Database Purist.
Saturday, December 09, 2006
 
 
You have to decide upfront: What is the outside-interface to my data? Is it the database itself? Fine, then put the validation-logic there, but keep in mind to provide a stable and maintained DB-API (e.g. Views, Procs)
Or is it my business-layer? Then provide an external API, keep it stable and put your validation logic in this layer.

just my 2 cents
Pragmatist
Friday, December 15, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz