Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
What is a model?
  • Hi. I come from Java, mainly, and I'm interested in Fuel, after having done my first site with CodeIgniter. My experience with CI has been rather nice, with some minus. Before choosing CI I had read that its documentation was one of the strongest points; and it is quite decent - but I wasnt quite satisfied with some concepts definitions, in particular, that of a Model - seemed too vague to me. I came to FuelPHP and (though a liked the introduction of ViewModels ) its basic statement about what is a Model seemed equally unsatisfying to me, perhaps even less so: "Whenever data needs to be retrieved, manipulated or deleted this should always be done by a model. A Model is a representation of some kind of data and has the methods to change them." This is very vague for me, it seems to encompass several kind of objets (or patterns). (Let keep ORM out of the picture to begin with) My first thought, after reading that, is: "Is a model supposed to be an 'entity-like' object, or a 'service-like' object? " That is, suppose I have a Model called "User", which typically would be related to a DB table 'users'. Suppose in some case I need to get three users: would this involve ONE instance of the User class (with a method getUsers() that returns three anonymous objects, or arrays) or would this result in the creation of THREE instances of User objects (that is - is a instance of the Model linked to a row of a table?) That quotation above is so ample, that one could answer: 'both' ( FOUR instances?).
    Are the methods of the User model associated with an instance of a user, or are they rather service methods (from a pseudo singleton class, or even static methods) that just receive and return data ?
    I've seen examples in which the User Model has both types of methods: some static (or 'service like'), some entity-related.
    Are the fields of the User model expected to correspond to the User table fields ? From what I've peeked a over some CI examples (admitedly little) the answer to this questions seems extremely vague to me, so as to render the concept of a "Model" very blurred (model User = any business code and data and database mapping related to the "User" , not tied to a controller-view) Not only I miss the entity-service distinction : there's also little discussion about 'level' (bussiness methods - data mapping) and granularity (a model per table ? a model per graph of objects?). Of course, one can just answer: Fuel/CI does not mandate anything here, do as you prefer, a Model is what you like it to be. I hope that's not the final answer.
    In any case, I'd like to read about the experienced developers here, what is a Model for them (even if there are different or informal designs - I'm not asking for rigurous pattern classifications here). If I'm missing some doc or discussion, pls tell me.
  • FuelPHP doesn't mandate how your models are defined and the documentation isn't meant to explain MVC because that's been done already in academic papers which are far more authoritative on the subject. In Java, it is common practise to have collection classes ("Users" ) and individual object classes ("User" ), you can do this in PHP too. You can also simply map tables to classes and columns to properties or vice versa, ORMs try to make this approach suck less (often at the cost of more overhead). I'm afraid no amount of documentation is going to help you, but here are some great reads:
    * Domain Model
    * Data modeling
    * Naked objects
    * Object BTW, if mods are reading this, can we have " and ) not replaced by a smiley (and badly at that)? Ty.
  • And if it helps, here is an explaination of Javaworld. To understand MVC in depth, you have to understand that it's build around several design patterns, mainly CompositePattern, ObserverPattern and StrategyPattern, but influenced by some others as well. For an interesting bedtime read about this subject, check http://www.apress.com/9781430229254. Matt has a Java background, so while explaining he'll link back to Java approaches a lot...
  • Perhaps I've explained myself badly, or perhaps it was the title of the post. I was not asking about "models" in general, the M letter of MVC. (I know about that, I've designed websites in Struts and Struts2/Webwork, etc. )
    I was asking about the Model in Fuel. If Fuel has some convention of prefixing some classes with "Model_" I expected that that convention meant (conventionally) something less vague that "related to the M in MVC" (can be a domain model object, or a data object, or a data mapper, or a service object, or ...)
  • I am not exactly sure if I understand what answer you're looking for, but here's what I believe models to be in Fuel (and many other frameworks for that matter). It seems to me that the term Model has been somehow made a synonym of Database abstraction... while this is probably the most common use, a Model, as I understand it is simply an object that represents data of any kind... and adds utilities to work with that data. Fuel seems to have an extremely loose definition of models. The framework allows you to decide how to implement them as long as it follows the design pattern. I'd imagine the most common use of Models in Fuel will be through the Orm\Data class... but there is no reason you could not define your own... Perhaps that's not the answer you're looking for, but the framework is relatively new... not everything has been set in stone (you can tell be the state of infancy in the docs). That's what is exciting me though, the fresh perspective and mixture of my favorite features...
  • Following what Frank said: I think FUEL is made so that you have the opportunity to do things the way you want to do them. It's flexibility it's awesome comparing it to other frameworks I've used so far (including CI as you mentioned it). I agree with Frank that the term Model has become a synonym for Database Abstraction or to be more specific: Database Entity Abstraction (as models are ultimately supposed to represent some entities). They also (and I'm pretty sure I'll receive some boos here but anyways) serve the 'administrative' purpose to separate your coding into easily identifiable pieces; meaning that if you encounter some problem between your application and the database, it is most certain the problem lies inside your model. It's like separating the whole into tiny bits: "Divide and conquer" right? So maintaining your code is less of a struggle this way. Having said that I'll just finish this reply with a quote from the Pirates of the Caribbean: Course of the Black Pearl movie:
    - Barbossa: "First, your return to shore was not part of our negotiations nor our agreement so I must do nothing. And secondly, you must be a pirate for the pirate's code to apply and you're not. And thirdly, the code is more what you'd call "guidelines" than actual rules. Welcome aboard the Black Pearl, Miss Turner." FUEL won't define what your Model should be/do/look like... FUEL will only give you some guidelines about it...
  • Hahahahahaha! We have an accord.
  • Personally, I'm more fond of the Mercedes SLR then the Honda accord. But they both run on fuel.
  • Lol. I like my VW Passat.
  • We are not here to tell you what a MVC framework is, we are here to tell you we have a bloody brilliant MVC framework. Various frameworks handle Models in a different way. Some are just singletons, some are essentially leaf classes or static methods that have no relation tio an "entity". Our models can be used for whatever you like. Our models are so flexible, because they do nothing. A model is just a class, which you can do DB interaction, pick apart an XML file, contain a bunch of MongoDB logic, whatever you like. What makes a Model different from any other class? Nothing. Why use a Model instead of a class? Up to you. Is there any point in having a Model? Yep, it's nice any tidy.
  • You seem to imply a model != a class. In RFC terminology though, it MAY be.
  • Foo Bar wrote on Saturday 7th of May 2011:
    You seem to imply a model != a class. In RFC terminology though, it MAY be.

    Huh? I said: "What makes a Model different from any other class? Nothing." A Model is just a class with a name in a seperate folder. It doesn't need any other logic attached to it as a Model could be abstracting over a database (many different types), XML, reading a CSV file, etc. It's separation from other classes is purely for easy distinction. You could delete the app/classes/model folder and just use normal classes and nothing in Fuel would break.
  • OIC, just above
    Why use a Model instead of a class?
    nvm then.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion