Drawing the line between models & libraries?

Question

As my webapps increase in size, so does the complexity. In order to keep my classes & files structured and easy-to-access, I am starting to get more and more confused:

I have some very clearly defined data objects in my application - orders, invoices, products for example. All of those have their own entity object that handles enforcement of values and pure business logic along with a model that handles storage of each object to my persistent storage of choice (database).

Ok - everything clear and separated that far. But what about a logic-heavy object like users?

Users log in and out, change password (with everything that means - hashing, encrypting and so forth) and do a whole lot of interaction both in the database and with Sessions.

Right now, I use an Authentication-class, a library, which carries all of these mentioned actions and a lot more. It does it's job, but It's kind of unclear to me what I should put into a model and what should be a Library?

Answer 1

I do think you kind of answered you own question - Models should simply include basic data-related logic, and every other more abstract functionality should be handled by library classes (IMO - should be taken with a grain of salt, as there are a lot of definitions of MVC and the likes for the web).

So, to extend on your example: the User class, would have setUsername, getUsername, setPassword, getPassword, validate, destroy, hash, encrypt etc. While it is true that logIn can be considered a data-related function, and can be placed in the model (matter of style and taste I guess), to me it looks more specialized and I would place it in a separate class called Authentication, which takes care of all User related, not directly tied to the data functionality.

To sum it up, I consider this to be largely a matter of coding style. After all, it should make sense to you as long as you develop/maintain it. And of course, it should be well-documented so in case someone inherits said code, they wouldn't get lost :)

Answer 2

MVC as we all know, is composed of Model, View, and All the rest.

Where does authentication fit? everywhere.

It's fundamentally a layer on top of MVC, but then it also needs to get back down into MVC to integrate itself with the View, and the Model.

Authentication is such an ongoing problem with the MVC model and with object orientation in general, they practically invented new paradigms to tackle it: one is aspect-oriented programming.

The only sure thing about aspects, is that Auhentication is one of them; apart from that, actual implementations diverge slightly: most concetrate on injecting function bodies before or after some other objects' methods. Defining the order of injections, the exact point, (called junction points) and the precise scope of the injected code is pretty debatable ...and the stuff of theorists.

So, if you feel every approach you take to deal with authentication seems incomplete and inelegant, you are not alone.

At least knowing there isn't a definite solution should put off some steam: most approaches that will come to your mind are as good as everybody else's. (as long as they work)

Answer 3

I suggest you to consider a concept of MVC design (Model View Controller)

Models are for communication with a database, controllers are for interaction with user actions and Views are for visual interaction with a user (display, templates)

For instance: In your example, all user related operations would have 3 parts: User controller which would consist of: adding, deleting, updating user info (but it would only accept parameters which it would send directly to user model which would be responsible for actual communictaion (operations) with database: add new user to database (on the basis of what paramenters has been sent by controller), delete user from database, update user info in the database... And view, would be a template for displaying user info, for getting parameters for user info update etc...

That's why php developers use existing frameworks or contruct their own. An application becomes much more modular, much easier for updating, refactoring...