OO logical question (DB Insert Method)

[Coolstep]

As far as I'm know, Functions which Add/Delete/Update an object is placed in the object's class.
like
class Emp...

Emp.addEmp(Emp newEmp)
Emp.delEmp(Emp oldEmp)
Emp.updateEmp(Emp currentEmp)

and in the Emp class I place my SQL satements.
If I'm right, my question is:
I have a class, the GUI to add new instances of this class enables the user to create more than one instance with one click. so I'll need to loop on insert statement, actually it's a nested loop, so where should the loop be placed? in the GUI class where I can see all the controls, or the Controller class(I'll have to pass different variables from control) Or in the Entity class (via Controller)

e.g.
My interface is like adding items to a lists, like selecting 3 items in 1st list and 5 items in 2nd list and so on. in DB each each record represents an item and its parent list. So to insert it I need to loop through lists and entirely through items.

Any help is appreciated

 

[chiph]

This is why you generally don't put your SQL inside your entity class. You'd break this into an Emp entity, and a EMP_DB class that would do the CRUD operations for an Emp.

To see why putting database access code inside an entity is bad, think about how you'd retrieve a list of 100 Emp objects. If the code to do this is inside the Emp class, you can't!

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[Coolstep]

Chiph,
Do u mean if I'm retrieving a list of 100 Emp, the Emp_DB would have a function to return me an ArrayList of Emp as example?
If yes, could this function be a static function in EMP? or it'd break a rule or convention?

I appretiate your help so much.

 

[grooke]

I'm now pushing marginal territory, so if Chip says I've got it wrong, believe him and not me.

Having said that, I would go back to my little boxes again. You have a chain of them:
1. The user, an actor outside the system who wants to create these things.
2. GUI which is the set of screens, frames, etc that the actor uses.
3. An Application Controller, which at its crudest just fires off the steps you defined in the use case.
4. Business Classes which are your Emps etc. I'll come back to this in a second.

Before continuing the chain, remember that a Database is another Actor. It can asynchronously fire off triggers. It can have the data changed by some other program running in parallel with yours etc. So dont be surprised if I make it look like an Actor and ALWAYs sepparate Actors and Business Objects with at least one layer of controller. (Robustness etc)

5. Data Controller, which marshalls the data for the database. This is where I think the SQL should go, and I think that is what Chip said.
6. Database API provided by the database provider. It takes the SQL and passes it to the database storage.
7. The Database as an Actor.

Now to return to the Business Objects. You seem to have 'Emps' and 'lists of Emps' at the very least.

Each object like Emp already has its own CRUD functions: constructor (Create), Destructor (Delete), Getters (Read) and Setters (Update). The 'lists' will have the same functions appropriate to the list, but getters and setters are replaced by adders and removers.

The methods you quote seem to be AddToList, RemoveFromList (Not DelEmp), and ReplaceItem in the list. These are not creating or destroying either Emps or Lists, but are manipulating Emps on the List. Maybe you need to create an Emp before you add it to the list; Maybe, after you remove it from the list, you destroy it etc; but these are sepparate actions which may not always be necessary. When playing card games you add and remove cards from lists (hands, stacks etc), but you never create or destroy them.

As I understand it, you are manipulating the Emps on a List of Emps. In fact, from your description of List1, List2 etc, you may have an array/List of lists, where again you need AddList, RemoveList, ReplaceList to handle it.

The key point is that, if you have a number of objects of objects in memory, you have to hold them somewhere. OO is good because it provides container classes like lists etc. but you do have to plan for them just as much as for the individual Emps. Then you plan the associations between the individual objects and their container class.

Everytime any of us miss a class from your thinking, we try to get the existing classes to do its work. Then it gets into a muddle. Good clear class models really work.

Gil

 

[Polu]

To map a relational model into an object oriented model is a difficult, recurrent and unresolved topic. Take a look here:

http://www.tek-tips.com/viewthread.cfm?qid=487289

 

[Coolstep]

Grooke,
It's not the first time I appreciate your tips . It's the professional way to have the system implemented, but what if the system looks simple that some of class layers u'v mentioned can be merged together. I'll tell u the structure and please correct me if i'm wrong:
1. A class that has the DB connections and fnctions which return a datatable, return a certain field or execute statement.
2. Entity Classes that represent the main entities. It also includes static methods to do DB transactions.
3. A controller class which holds some static variables and objects like the currently logged-in user object. Also I added to it other static functions that return datatables that help the interface display like (filling Comboboxes, filling grids and making some validations related to DB) So it includes SQL statements that serve all interfaces.
4. GUI Classes which represent the different interfaces for the system.

Your help is appreciated.

Polu,
I'm still new in development using OO so can you simplify your comment, or map it with my question so i can understand it? Thank you for your time.

 

[chiph]

If your app is pretty trivial, you can merge some of those layers together:

-- GUI
-- Entities (Emp and EmpList)
-- DB Code (CRUD operations on the database to read/write Emp and EmpList objects)

If your app needs to scale, or needs to interface to a lot of other systems, you (generally) want lots of layers, each of which is rather thin, so that the responsibilities of each are tightly defined.

Otherwise, if there's some overlap in responsibilities (business rule enforcement in the DB Code, etc), that can be done, but it needs to be consistent.

With regard to your original question -- can you have a static method to return a EmpList? Yes you can, but I still wouldn't do that. That makes your Emp class do a lot more than it ought to. Also, it bulks up your Emp class, so that every time you create an instance of one, you're using a lot more memory than you otherwise would.

It also makes the Emp class much more difficult to test.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[Coolstep]

Chiph,
As far as I can understand, I should have an Emp class to hold only my Setters & getters and any other validations on the entity level. Emp_DB to handle the CRUD operation. EMP_DB seems to be static, right?

What about sql queries that not related to a certain entity, it just help me to validate some actions on user interface of fill user controls like ComboBoxes and ListItems... Where to locate these Queries?

One of the most times I feel Joy is when I learn something that I always wished to know, Thank you Chiph and I thank all who shared here

 

[grooke]

Chip and I are giving the same message. It is better to over-divide than under-divide, but better still to be pragmatic. The latter needs experience, so your choice is limited; I have to err the same way as my main job is away from analysis and design. Chip puts it as ".... can be done, but it needs to be consistent." where the dots stand for some pragmatic method.

I want to just mention your reasons for wanting to mix the layers in the four numbered sentences:
1. DB Layer:- Fine.
2. Entity Classes:- Follow Chip's advice on static methods.
3. Controller:- This is the hardest to get correct, and maybe Chip's idea of ignoring it is simplest. However, I actually think it is very important; its the bit you will change most often at a later date.
Your idea of recording the user logged in is a good one. This layer pulls apart the data that comes across the GUI and decides whether this is to do with logging in or amending the accounts. It then calls the appropriate business entities to do this. Then the accounting program can be totally free of concepts of logging in.

You also seem to want to keep some SQL at this level. Why?
The work flow validation seldom needs it and the data for 'filling Comboboxes, filling grids and making some validations related to DB' should come out of the business classes, who will get it from the database, if they dont already have it to hand. Going down the layers sounds complex, but in general it is not. It takes a few percent more time, which you gain back as soon as you find that you are getting confused, because you can see what is happening quicker.

4. GUI - Dont validate in the GUI! Then break this rule if the final system is to sluggish.
All validation is best done at the business classes. The Controller can resolve which entity classes are appropriate etc, which may involve some business rules, but grids, lists of valid data, validity checks nearly all belong to the business classes.

 

[chiph]

What about sql queries that not related to a certain entity, it just help me to validate some actions on user interface of fill user controls like ComboBoxes and ListItems... Where to locate these Queries?

If you need to make sure that certain combinations of values that the user selects are valid, either in code or in a DB query, like grooke says, it would be best to put it in a controller class (that would make further calls to a DB layer class if needed). That way the rules are centralized and easy to maintain. But if your app is small enough, that might be overkill.

Search for "Model View Controller" on Wikipedia, they've got a really good article on it.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[Coolstep]

More questions!
As I told u in my application, my controller a static class and including static methods. some issues are not clear in examples I'v seen till now:
1. In all examples I'v seen Controllers are not static, I can't imagine a controller not static
2. In one example the Controller was inheriting from Windows.Forms just to handle fired events which I can't imagine how to handle it while they'r fired at GUI classes.
3. Is it acceptable to place any SQL statements in Controller or View Layers?

Thank you guys for ur valuable tips and I guess what I miss now is just some examples of big applications implemented using MVC just to get closer to understand it and apply it correctly

 

[dragonwell]

If I may chime in, regarding the controllers being static - You may want a controller to maintain data that is unique to a specific session. For example, one responsibility of a controller could be to guide a user through a multi-step wizard, in which case the controller could have instance-data. You would create a new instance of the controller at the beginning of each use-case session. If your methods are static, all users/sessions will have to share any data stored in the controller.

 

[BobRodes]

If I may chime in also: the reason that the controller handles fired events is because the way in which they do so is dictated by business rules. The MVC pattern is roughly analogous to the 3-tier pattern that Microsoft espouses, with model being the data tier, view being the presentation tier, and controller being the business tier. You can easily find a good deal of reading material on both.

The point about encapsulating these different aspects of an application from one another is that changes to each typically do not involve changes to the others in a practical sense. For example, if the company decides to migrate from Access to SQL Server or Oracle, it would be well not to have to muck around in code that expresses business rules, or code that presents data on a form. Likewise, if the business rules change, that shouldn't impact code that implements data access methodology, and so on.

The reason that controller is seen as not particularly static is because business rules tend to be somewhat volatile.

As for being pragmatic when working with what to put where, a good way of evaluating this is to apply the concepts of cohesion and coupling. A well-formed object is both internally cohesive and loosely coupled with other objects. To spot design problems along these lines, first check for excessive decision logic inside a class. This is an indicator of a lack of cohesion. An object that spends too much time deciding what it's supposed to do spends too little time doing it, and is therefore inefficient. Consider breaking the object apart. Then, check for too much communication between objects, which is an indicator of overly tight coupling. Again, objects that spend too much time messaging other objects create extra overhead and are therefore also inefficient. Consider encapsulating the functionality of these two objects as one.

HTH

Bob

 

[Coolstep]

Thank You All guys for your efforts