Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'm not familiar with everything CodeIgniter does, but think of it this way:</p> <p>For MVC, M is big and hard to generalize, whereas C is very small (and the V should be pretty obvious). Remember the principle: Thin Controllers, Fat Models (<a href="http://www.bing.com/search?q=thin+controllers+fat+models" rel="nofollow">http://www.bing.com/search?q=thin+controllers+fat+models</a>)</p> <p>Now, to address your question, this is something that took me a while to learn. The "Model" that most frameworks talk about in the docs is not all there is to the "Model layer". You can also think of this as a "Service layer". Remember, controllers are "thin", so they should be simple. They should do things like, get input from the request, pass it to someone else to store in the database, get some data, send it to the view. Controllers facilitate things. The Model/Services, handle all of the logic. The "models" you are referring to are just one small piece.</p> <p>So you have a <code>BookModel</code> and <code>LibraryModel</code>. But maybe you also have a <code>LibraryManager</code> which keeps track libraries and passes books between them. Or a <code>BookParser</code> which will load up some XML and generate a <code>BookModel</code>. Or a <code>Translator</code> which will take a book and translate it into another language and produce a book.</p> <p>Do you see how the "model" is hard to really define as just 1 or 2 classes? It all depends on your application.</p> <p>Think of the design phase this way. Write controllers with pseudo code. Like "Save this book", or "Export a list of books", or "Check out a book from this library". Then, don't think about the framework, just design your "business logic" to do those tasks. So you figure out what classes you need based on what you need to do. You can probably keep the <code>BookModel</code> and <code>LibraryModel</code> as a way of representing the data. But you will likely need to go beyond that depending on what you want to <em>do</em> with that data. Of course, the framework will often handle a lot of the "service" layer for you. You probably don't have to write the class to access a database, but use your framework's database service to CRUD your <code>BookModel</code>.</p> <p>Another OOP principle make classes focus on doing one thing (Single Responsibility). So don't make your <code>LibraryModel</code> also responsible for lending out books, determining the top 5 books, and every other thing you want to do. Just focus on storing the data about a library and make another class responsible for the actions on it (<code>LibraryLender</code>, <code>BookRater</code>).</p> <p>Okay, well, hopefully this is helpful and not just nonsensical ramblings...</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload