Where does the query language sit within the MVC pattern?

Question

I'd assume that since the query language sits within the controller (typically) that it belongs to that component, but if I play devil's advocate I'd argue that the query language is execute within the domain of the model, and is tightly coupled to that component so it might also be a part of it.

Anyone know the answer? Is there a straight answer or is it technology specific?

Answer 1

Both are legitimate ways to implement it. The question is what and how you need to expose your application to its users. In Patterns Of Enterprise Application Architecture (figured again, that I really like to quote that book ;) they offer two ways to implement the Domain Model:

• Implement all application logic (and therefore the query language) in the Model. That makes your domain model very use case specific (you can't reuse it that easily since it already has some application logic and dependency to the backend storage being used) but it might be more appropriate for complex domain logic.
• Put the application logic in another layer (which can be the Service Layer being used by the controller in the MVC pattern or the controller directly). That usually makes your model objects plain data containers and you don't need to expose the whole (probably complex) domain model structure to your users (you can make the interface as simple as possible).

As a code example:

// This can also be your controller
class UserService
{
    void save(User user)
    {
        user.password = md5(user.password)
        // Do the save query like "INSER INTO users"... or some ORM stuff
    }
}

class User
{
    String username;
    String password;

    // The following methods might be added if you put your application logic in the domain model
    void setPassword(String password)
    {
        // Creates a dependency to the hashing algorithm used
        this.password = md5(password)
    }

    void save()
    {
        // This generates a dependency to your backend even though
        // the user object doesn't need to know to which backend it gets saved
        // INSET INTO users
    }
}