Libraries or Models, favouritism?

[eluser]Hyra[/eluser]
Well that leads us back to the main point .. models, libraries, favouritism?

Seems to me pretty much any non display functionality/logic ©(sh)ould be encapsulated within a model. This makes the most sense to me anyway.

Which makes the whole "libraries" concept obsolete.

Edit: sorry, i see you actually extended a library there. But this could just as well be handled within a model if it wasn't an extension of the form validation?

Im trying to come up with another example to make my "point" clearer, but failing miserably.

But maybe that's exactly my point: the fine line between model and library is simply that .. too fine?

[eluser]wiredesignz[/eluser]
There is a distinct difference between a library and a model, and a definite place for libraries. Just look into system/libraries and see that CodeIgniter would not function as it does without libraries.

[eluser]Hyra[/eluser]
Well I gathered as much from the documentation and the way CI works.

Thing is, as a developer, what should make the final decission between putting your class in the libraries folder and when would it go in the models folder.

Simple routine functions with a little bit of complexity would classify as libraries. But if you add a decent amount of database interaction, does it become a model? (Definately not both, that would make the code clumsy)

So yes, I do get that there's a difference, but does db interaction decide which one of the two it is?

[eluser]wiredesignz[/eluser]
The MVC design pattern suggests that there is separation of concerns in an application. You need to study MVC and then decide for yourself.

Heres a site that helped me understand. http://www.phpwact.org/pattern/model_view_controller

[eluser]xwero[/eluser]
You are right you as a developer has the final say in what to use or not. You can start putting everything in the controllers and once you are seeing you are copying code you check if the abstraction doesn't create too much overhead (memory, execution time) and abstract the code into a library. If you see you are copying queries in your code you can put them in a model.

The difference between a model and a library is that the model library gets loaded by default which means it already knows the CI object and does a check if the model is already loaded or not. In a library you need to code this yourself.

The model library is created because it's a part of the MVC pattern the framework uses to make the code easier to maintain and reuse.

If you want to create your own model library no one will stop you. If you have your own DRY methods we want to know them it could be interesting to learn from.

[eluser]jbowman[/eluser]
[quote author="xwero" date="1204038330"]
You can only use that query in that library. If you put it in a model you can call the query in any library you want.
[/quote]

Libraries should never call models. MVC is the structure of the application, libraries are utilities to be used by those three elements to accomplish tasks.

[eluser]xwero[/eluser]
[quote author="jbowman" date="1204056529"][quote author="xwero" date="1204038330"]
You can only use that query in that library. If you put it in a model you can call the query in any library you want.
[/quote]

Libraries should never call models. MVC is the structure of the application, libraries are utilities to be used by those three elements to accomplish tasks.[/quote]
I think that is more a semantic issue. CI is very open in the use of the MVC pattern and that is one of its strengths, especially for new comers. As i said earlier in this thread you can put everything in the controllers and it works.

For me is a model a class where you add data methods, which is the definition of the model ? I could call it database or xml or something else. It's about keeping similar functionality classes together. And because models is already initiated what is the point of adding another class to group my data methods with other than losing more memory? Or do you have another method to do this?

[eluser]Pygon[/eluser]
Here is my personal opinion:

Libraries: Standalone classes/functions. Data interaction is restricted (as best as possible) to that which is supplied by function arguments. Access to methods/functions should be limited (again, as much as possible) to the library sudo-namespace. Processed data is returned to the caller. As jbowman put it, these are "utilities" or tools to accomplish a task.

Model: Data accessor/store. Stores, manipulates and retrieves data from internal or external sources for use by the view. Methods/functions will likely use libraries to aid in data access or manipulation.

Example using a PDF document:

Library contains functions to creates a generic PDF documents and returns this document to the caller. No project specific methods.

Model contains project specific functions for storing data to be contained in a pdf document, methods for manipulating such data prior to creation (within the model), methods which request the library create such document (stored back into the model) and methods for output to file or browser.

As you can see, in my opinion, a library is generic in nature, has no knowledge of the data you are working with or the source of such data. With little change, a library could work as a standalone php script completely outside of CI. A model, however, would be far more project dependant and unlikely to function as intended outside of CI without heavy modification and dependancies.

[eluser]Hyra[/eluser]
This classification (sorry ) leads to believe one would need both model and library for certain tasks though.

Let me use your PDF example.

You end up with both pdf_library.php and pdf_model.php

Another example, authenticating users

auth_lib.php
Which does the formchecks for the login method (or should the controller do this before calling the login method), handling the registration of a new user (or is this a models work as you enter new data in the database), and send out a confirmation mail (goodie, this one looks like it actually belongs here)

auth_model.php
Which contains the methods to store the users data, methods to check if a username is already taken, called from the library.

As you can hopefully understand from my point of view (or MVC in general), above example, should just be in a model, and be called by the controller, as it mainly does database actions. The rest (form validation and sending the mail) can be controlled by using the form _library_ and the email _library_

Maybe i was doing things correctly all along and should just stick to using/creating models for the processing of the data, using the prebuilt libraries of CI "as is". Think i just got confused by finding all sorts of "Auth Libraries for CodeIgniter" which confuzzled me as to what the difference between a model and a library actually is

[eluser]jbowman[/eluser]
Going to just walk away from this one, leaving one thought. The purpose of the MVC isn't as much to add functionality as it is to provide structure. It's more efficient to write the entire application as one php file with hard code sql queries. The purpose of the MVC structure is to provide a structure which makes the entire application code easier to maintain. In order to do this, you need to follow the standards of the application flow. That is why you would not want to call any part of the MVC hierarchy from a library.

Based on what I'm seeing in advice offered in this thread, I see some don't agree. I'm not going to argue or debate whether or not it's a strength of CI that you can do it. Really, you can do it in any of the PHP MVC frameworks. I'm just stating the original purpose for the entire MVC concept, which was to provide an application development structure to enhance the ability to maintain and update the code in the future.