I've approached the development a library/book management system by using the CodeIgniter framework. I'm new to all this, and have my own way of learning, so bear with me if it sounds like a daft question.
I'm getting to a point where I've got questions about concepts and design.
I've got lot of views, a controller that does most of the work, and one model. I'm now realizing that whilst this is all nicely MVC, it's not necessarily well structured. For example there's lots of reference about one table/one model and so on.
So I can separate my model into a libraries_model and a books_model easily enough. But what I'm not sure about is this:
1) Is my books_model the book object (conceptually speaking)? Or should I be creating a separate "book object" which obviously uses my "books_model (this is MVC after all). i.e. Are they one and the same thing?
2) If they are the same thing, then I would only have my books_model, stored in the model folder of the CodeIgniter folder structure. If not, then where would I be advised to put the book object (that is not the model)? In the core folder?
I've got a feeling that they are indeed the same thing, but I just don't know how to confirm it, short of asking those that know :)
I'm not familiar with everything CodeIgniter does, but think of it this way:
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 (http://www.bing.com/search?q=thin+controllers+fat+models)
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.
So you have a BookModel and LibraryModel. But maybe you also have a LibraryManager which keeps track libraries and passes books between them. Or a BookParser which will load up some XML and generate a BookModel. Or a Translator which will take a book and translate it into another language and produce a book.
Do you see how the "model" is hard to really define as just 1 or 2 classes? It all depends on your application.
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 BookModel and LibraryModel as a way of representing the data. But you will likely need to go beyond that depending on what you want to do 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 BookModel.
Another OOP principle make classes focus on doing one thing (Single Responsibility). So don't make your LibraryModel 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 (LibraryLender, BookRater).
Okay, well, hopefully this is helpful and not just nonsensical ramblings...