Page 1 of 1
What does Model mean indeed?
Posted: Thu Oct 21, 2010 4:19 pm
by VladSun
I've read plenty of articles, examined plenty of code snippets and written a plenty of code myself. But I still get confused when I use the so called "Model". Every time I see "subModels" - i.e. UserCollectionModel, ProductCollectionModel, etc., but it's not the *application* Model, but a very tiny part of it.
In my current project (a
LARTC router) I've implemented an event driven system in order to notify all related submodels (I called them "plugins", but they are not plugins indeed) about changes in the currently used submodel. I.e. if I modify the UserCollectionModel I need to change the DHCPUserCollectionModel, PPPoEUserCollectionModel, etc. All of these exist in the "application Model", but the current Controller (i.e. the UserController) has loaded just the UserCollectionModel as it's Model.
So, I think it has to be a one really big composite application Model (I think it should be a Facade pattern) and all Controllers/Views should use it. I understand that "one really big composite object" is the worst practice in OOP, and that confuses me even more.
Comments, suggestions, ideas?
Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 5:14 pm
by Weirdan
My current understanding is that the model is an application layer, not the concrete parts of this layer. Thus there's little sense to talk about User model (no more than talking about Vlad (sic!) nation-state).
If you're familiar with "traditional" unix programming, you might be aware that software there comes often as a library + interface part (often, but not necessarily, a cli executable) tandem. My perspective is that the library here is application's model, implementing core application's business and providing API to control it, while interface part is essentially controller + view. Let's take curl for example - libcurl handles all the heavy-lifting (talking to sockets, handling protocols, etc). It doesn't really depend on the controller/view part, thus you may implement various interfaces to it, be that GUI, unix cli, Powershell commandlet, language bindings, etc.
I realize this understanding of Model is very broad (intentionally so!), and there might be more specific schools of thought, but I think it really captures the essence of what Model is (separation of concerns) without going into specifics like what kind of interface the model layer provides or how it's implemented internally. Yes, I think it's possible to use MVC without employing any objects

Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 5:48 pm
by VladSun
Yeah, all of this is true.
But I'm more concerned about the composition itself of the "Application Model" - i.e. the application layer as a whole.
In my concrete project when I delete a User I should also delete the PPPoE user related to that User. The User "submodel" is not aware of the existence of the PPPoEUser "submodel". While the PPPoEUser knows about the User "submodel", I think it's up to the what I call "Application model" to apply changes to the related models, because it knows all relationships between "submodels" and it's really the only "Model" in the system.
You may apply Controllers/View, GUI, CLI, etc. to this "Application model" - in this sense it's more like a library (though it has a state).
Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 6:33 pm
by Weirdan
VladSun wrote:
But I'm more concerned about the composition itself of the "Application Model" - i.e. the application layer as a whole.
Nowadays I tend to prefer to have a limited number of coarse-grained (and essentially procedural) facades, reflecting areas of functionality, like UserManagement, HardwareManagement, etc. This suits the application I'm working on, and matches the language our client provides in feature requests.
Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 7:08 pm
by Christopher
Weirdan wrote:My current understanding is that the model is an application layer, not the concrete parts of this layer.
I haven't a clue what that means?
Weirdan wrote:Yes, I think it's possible to use MVC without employing any objects

That is true for any software. The question is which of the possible things are actually a good idea to do?
I think you are missing the point that the Model is the part of the software that is modeling the external (real world) thing that the software represents. It should be clear that the I/O parts of the system (e.g. a keypress or click, a screen layout, an adapter to some data store) are obvious not part of the real-world problem. So everything else is the Model. Examples of things the Model are users, orders, products, posts/comments/messages, etc.. Also any calculations or transforms of those types of things are in the Model. The thing the Model manages are often "data" in databases sub-systems and files.
Typically the Model is in its own layer -- above it is the Presentation layer, below it is the Datasource layer. Individual classes in the Model are also called Models. This is why the term Domain or Domain Model is sometimes used to differentiate individual classes from the whole layer.
Specifically to the OP, I don't think there is a problem with composite objects. That is the way things should be constructed. Not is there a problem with complexity as long as the design is managing it.
Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 8:15 pm
by Weirdan
Christopher wrote:
I think you are missing the point that the Model is the part of the software that is modeling the external (real world) thing that the software represents. It should be clear that the I/O parts of the system (e.g. a keypress or click, a screen layout, an adapter to some data store) are obvious not part of the real-world problem. So everything else is the Model. Examples of things the Model are users, orders, products, posts/comments/messages, etc.. Also any calculations or transforms of those types of things are in the Model. The thing the Model manages are often "data" in databases sub-systems and files.
Been there, done that. Didn't like the results. This might be just not my cup of tea, but I think if mechanical engineers were 'modelling the real world' we'd be driving mechanical horses by now, not cars. In my practice naive approach of reflecting things in code never really worked well, in all cases but the simplest ones like CRUD. I'm more likely to have UserManagementFacade using BatchInsert + TransactionManager under the hood than collection of Users and Groups. 'Transmission' makes more sense to me than 'muscle moves the bone that moves the joint that moves another bone that moves muscle attached to it'.
Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 8:28 pm
by Christopher
Weirdan wrote:Been there, done that. Didn't like the results.
Perhaps the the reason you didn't like the results is because you haven't actually been there or done that.

Re: What does Model mean indeed?
Posted: Thu Oct 21, 2010 8:41 pm
by Eran
While I think the real-world comparison is not appropriate when we are talking about software, where many of the elements have no physical equivalent, I agree with Chris that models are supposed to model domain entities (real or digital). Application classes that do not fall under either of the M-V-C tiers is what I call utility classes. So for your example, 'UserManagementFacade' is what I (and probably Chris) would call a 'Users' model. BatchInsert and TransactionManager both sound like utility classes, not models. They implement logic that is not (I assume) specific to the application domain but rather deals with system constraints, and most likely they are transferable between projects.
In Vlad's example of multiple classes dealing with user collections, I would composite those into the Users model instead of subclassing. When you need to deal with protocols in the Users model, you are actually stepping out of the application domain and into the system domain (business logic -> system constraints) - so I would pass an instance of the needed protocol in the relevant methods. In my view protocols would not be models, but utility classes that are used by the models as necessary.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 1:46 am
by Christopher
I agree with Eran. And the thing about these entities discussed above is that there is no mention of their dependencies. Things like Utility classes that Eran mentions could just be helpers so not really in any layer. But they could also be in a different layer, for example below the Model layer providing access to the system. Looking at what the dependencies are (or should be) will let you know where a class resides.
PS - by "real-world" I don't mean physical. Most of what we model are really just concepts. Orders are an example of a thing that may be associated with a physical stuff or not (e.g., such as reservations or software), but in our usage it is really an accounting concept. And even with actual physical things, we are usually not actually modeling the thing but the information associated with it. For example, for a User we are really modeling the folders in the HR and Accounting Depts. -- not bones and tissue. I think this is a common misunderstanding exacerbated by bad examples like the Car class.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 2:41 am
by VladSun
I'm arguing that there are no "User", or "UserCollection", ... Models because these are only tiny parts of the business model. If all the application can done is dealing with User records, then - yes, the UserModel is a Model. Otherwise it's just part of the Model and thus it can't be called a Model.
I'm arguing that every Controller should load the "application" Model, because it's the only object which knows "everything".
I think, multiple Model Facades and lazy object ("submodel") loading could be a good solution to what I want.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 7:26 am
by Eran
I'm not sure I understand what you mean Vlad. A Users model can be a small part of the business logic - but why does that not make it a model? you can have many models in a system.
The controller is the application logic layer while the model is the domain logic layer. If the application layer knows everything, you have less separation of concerns which usually leads to more complexity and dependence between parts. The point of having models is that controllers are not reusable in the application - they can only be used once usually. Models can be used in many places since they do not depend on specific states of the system.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 8:58 am
by Jenk
It's my belief that the Model is the "business rules"/"domain" part of your application. Anything that is doing something because of a business rule required by the owner of the product. Example, we are writing software for the logistics industry, so anything to do with handling of a delivery, is the model. The "other stuff" are only there for technical reasons - the data, the presentation (view) etc.
I'm often saying things like "The Delivery Model" etc. where all I mean by that, is the Model of the Delivery feature, or area of concern just so I'm not involving areas of the application that are irrelevant in the conversation.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 1:36 pm
by Christopher
VladSun wrote:I'm arguing that there are no "User", or "UserCollection", ... Models because these are only tiny parts of the business model. If all the application can done is dealing with User records, then - yes, the UserModel is a Model. Otherwise it's just part of the Model and thus it can't be called a Model.
I'm arguing that every Controller should load the "application" Model, because it's the only object which knows "everything".
I think, multiple Model Facades and lazy object ("submodel") loading could be a good solution to what I want.
I think you are mistaken that the "Model" is either only the whole Application/Domain/Model Layer or only individual classes in that layer. Whether you say they "can't be called a Model" is irrelevant -- because they are both commonly called the Model. The terms Domain Model or Business Model/Logic describe all classes/code in the whole layer. But because of patterns like MVC, the term Model is also used to describe individual classes. I don't find the reuse of the term in generic/specific contexts confusing.
I don't think there is any expectation that the whole Domain layer code is loaded in a PHP request, except in very simple apps. So what you call "Model Facades and lazy object ("submodel") loading" is the norm in applications. And that could be loading 1..N distinct Model classes or loading a Model that has composite siblings or children.
Re: What does Model mean indeed?
Posted: Fri Oct 22, 2010 8:12 pm
by josh
Vlad, I get the sense you view the whole 'model layer' as a hierarchy of models. It is in fact a graph of models. "Sub-model" and "application-model" are confusing, meaningless terms to me. Especially 'application model' (I would call that a transaction script or ball of mud). A 'transaction manager' and a 'transaction' are both models to me. I find its easier to define what a model is not:
A model is not presentation logic.
That's the only definition I can give. Controllers are presentation logic, contrary to popular belief (even the creator [lead developer] of Zend Framework debated me, trying to say controllers are not in the 'presentation layer', but numerous other programmers stepped in and agreed with me. I guess a lot of people don't understand that presentation logic does not imply 'templates'. A template is a type of presentation, there are more types of presentation logic than templates.) If it has anything to do with presentation, it is not a model. If it contains no presentation, it is a model. If it contains both presentation & non presentation logic, its a mud ball.
I don't think 'application layer' is a useful term either. There is a presentation layer, and then there is a model layer. Within the model layer you can create your own layers. 'application' is one of the only forbidden terms to me, when naming a layer or model. An application is an application. I leave it at that. The only time I would use the word 'application model' is if I was writing software to help people create applications. Or if I was writing a 'hotscripts.com' clone, I might have an application model to represent each application. But never a 'application model' in a god object, or facade sense.