Have I applied this 3-layer design pattern properly?

[G_S]

Hello everyone.

I am modeling a simple dictionary application using the presentation-business logic-data layer pattern. I already have the design but am not sure it is correct:

My presentatioon layer is a simple GUI where users insert their queries. They have a form for entering new words and their definitiom and also another form for querying the dictionary. I think this one is OK.

My Business layer is where the trouble starts: I have an Entry class which has the attributes id_number (for queries), word and definition. As for methods it has the standar CRUD operations. It aso has some transformation methods used for formatting the input (removing plurals, removing gramatica genders, etc.) The CRUD methods simply build a query using the attributes available and immediately instantiate a connection class.

The third layer would be the data access layer. The actual SQL pocessing is being carried out here. The previous object simply builds a query but it doesn't run it. This layer has a special class for running SQL after checking server connectiona nd all that stuff.

Is this properly implemented? Should the Entry class rather be in the data layer? If so, what should I punt in the logic layer?

Thanks in advance.

[DaveAmour]

This can be quite a subjective topic sometimes.

Have a look at Active Record versus Repository Pattern eg:

http://stackoverflow.com/questions/6522009/active-records-vs-repository-pros-and-cons

I think Active Record is not so good anymore so go for the more decoupled design.

[JamesCherrill]

IMHO that's the standard OK implementation for a simple application.
One would expect to see the middle layer consisting of (at least) a Dictionary class that holds a collections of DictionaryEntries, with methods that add or remove entries or change the collection itself. In the entry class I would expect all the methods that work with individual entries (eg formatting). SQL has no place here, that belongs in the data layer.

[G_S]

Alright. According to James' answer, the new design would be:

FIRST LAYER: GUI
SECOND LAYER: a class for storing and processing the data obtained from the GUI (lowercase, lematization, etc.).
THIRD LAYER: two classes: one for managing database connections and sql execution, and the other for building the SQL and asking the former class to run it.

Is this better then?

[JamesCherrill]

IMHO yes.
Second layer holds the data model, and has all the methods relating to that - it's not dependent on the GUI (ie the GUI depends on the model, not vice-versa)
Third layer: could be any number of classes. The important thing is to define its interface or "contract" - typically a set of public method signatures that you can call on to initialise the data store access (eg supply user name/pw to open a connection) and load/store/search model data.

This is just a classic basic three tier architecture - documented and discussed to death on the web. Here's a very short but clear version:
http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture

[G_S]

Thank you very much. I know it's widely discussed, but I had to resort to this website because my teachers really confused me when they told me that MVC is the same as third-tier architecture and that the data layer is the one in charge of the logic AND data...

But wait, you say the second layer holds the data model. Shouldn't that be the third layers job, data processing being the second's?

[DaveAmour]

The point is there are different ways to arcitect things. A simple n-tier (typically 3) was favoured for a long time but more recently a service based approach with looseley coupled services and dumb poco models is more fashionable. If you are doing this for an academic course then best to stick to what your tutors want though.

A good technique to use though, whatever architecture you are doing is an architecural spike. This is when you code a small vertical part of the app such that it touches every layer from the UI, through the business logic, the data access and the database.

This way it allows you to fine tune your layers and tinker with them until you are really happy and then coding the rest of the app is just more of the same.

[JamesCherrill]

Yes MVC is a three-tier arch, but it's not the only one.

When I say "data model" I'm referring to a convenient representation of the real-world domain - classes like Customer or Invoice etc with all their attributes and behaviours. Maybe I should have just said "model".

The third level is just data - sets of ints, floats, strings etc and the code they need need to be stored and maintained somewhere.

It's the middle one that matters. It must reflect the real-world problem accurately. You may use multiple top layers (local GUI, web server etc), and may exeperiment with different bottom layers (SQL, hibernation etc), but if you mess up the model your app will fail.