Re: [fw-mvc] Application structure

I've built a domain with some objects that works pretty smooth for my needs. Mostly just a little experiment to get more experience around domain modeling. I have data objects,data mappers and some other stuff. Works pretty smooth.

Now I've come to the point I want to do something as simple as making sure that a username doesn't already exist. Just pretty much doing that, as it's going to be used with as a json service that just answers whether or not the username is taken. I'm not sure how I want to accomplish that. One way could be to try to map a User object based on the username, and check whether the object was created or not. But I feel I want to take a more util/serivice approach, more like a count of results rather than trying to map the data. I'm not sure where I want to put such logic. UserUtil, UserService, make a Username Validator?

Happy for any ideas, insights.

Thanks!

On Mon, Sep 22, 2008 at 10:47 PM, Nino Martincevic <don@zampano.com> wrote:

Jiří Němec wrote:
> I would like to ask about "where should I put the code". Sometime
> I am asking myself, should I put this code into model or leave in
> controller or create own library class..?

First question:
What does "code" mean to you?
A function to output debug messages is code, a method to determine the time difference between two events is code, showing a web form is code...

The question is wrong. It could be in the form "Who (in terms of objects) has the responsibility to do *this*, who has the data and who is needed to fulfill the required functionality?"

But not where to put something into before you know what this something actually is.
First have a good concept (a logical Domain Model) of your application then ask where to put a particular code. In most cases this question where to put something in does not need to be asked anymore. But gets answered from *your* requirements.
(the *your* is very important, it's your application and context that counts, not any other)

> submitting there is need to validate data (should I do it directly in
> the controller or in a library...?),

Ask yourself the question:
Image another UI or application (can be really imaginary, perhaps you will never build it. Can be an API, a Webservice or a CLI app), working on and with the same business logic, can it work the same way? Can and should it validate data by itself (e.g. in its controllers) or do you duplicate code by letting app B do the same?
And may the controller of app A or app B validate data or is it a business concern, is this their responsibility? And if you change it in one do you break the rules of the other?
Or can I use rules provided and checked in the business layer encapsulated from and valid for all possible clients?

The answer should be obvious then where and how to handle validations and rules (though there are many implementation concerns...)

That way you can also answer many questions regarding where to put your code into...
;-)

> then I save a user account data
> (again, do it in the controller, model or a library which will
> cooperate with a model...?) into the database table...

From Wikipedia:
"
Model:
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data [...]
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model."

The last sentence is the most important. Keep you objects and your model as meaningful, decoupled, cohesive and persistance ignoring as possible.

> I am asking you because when I looked over your quick start
> application, there is in GuestbookController two protected functions -
> _getModel() and _getGuestbookForm() and, maybe I am totaly wrong, but
> this doesn't fit in my concept of M/V/C separation (I would rather put
> this code into separeted class object which returns a concrete form
> object).

One way is to think in layers (or tiers): (http://en.wikipedia.org/wiki/Three-tier_(computing)).
The controller is a kind of application layer, handling the requests and delegating them to the service/domain layer (aka Model) and vice versa and rendering/updating the view.
It is an extremly thin layer, with almost no logic, just for the actual UI (and only for that). And for the functionality of one *specific* application/UI  but not the business logic.

There is a slight difference between the classic three-tier (or n-tier) architecture and MVC: the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model (Wikipedia).

This is debatable and in my opinion leads to many many wrong adaptions of MVC and poor oop design.
I think this is just infrastructural or technical thinking.
If you think in business (domain) models, responsibilities, decoupling and encapsulation you would never let the Model update the View.
That's simply forbidden in a layered architecture (there are ways to do it legally though...)

At least a perhaps too simple sounding advice, but it always helps me when I'm stuck again:
Follow at least the main OO principles (esp. DRY and SRP) and you will almost
ever find a way to a better (not perfect!) design.
And the right place for your code :-)

But it's always a hard work and fighting against bad habits, antipatterns, laziness and hacks....

Cheers!