Confused about libraries vs models

[eluser]Buso[/eluser]
Suddenly I found myself writting library methods like this one:

Code:

public function some_func() {
  
  $this->CI->load->model('some_m');

  $this->CI->some_m->some_func(); // this is the same name used for the library method

}

So I'm not sure anymore about when I should use libraries instead of models.

It was very clear in the beginning, when I used to think that models should only contain database related code. But now that I use tiny controllers and big models/libraries, the only difference I can see is that models can do $this->db, and libraries don't. Maybe models are only for CRUD, and libraries are something like 'subcontrollers' (meaning that they take some kind of decisions) ?

Please enlighten me.

[eluser]umefarooq[/eluser]
in library you can also use db function same has how your are calling model in library you can directly call database active records

Code:

$rows = $this->CI->db->get('table')->result();

[eluser]Buso[/eluser]
I know..

I was just mentioning the only difference I could see

Also, the model can inherit methods from a base model..

But I could have a base library too, i dont know, this is confusing u_u

[eluser]mddd[/eluser]
In the end it is up to you, but I think the general idea is this:

- Controllers manage the flow of what has to be done and what has to be shown.
- Models take care of the 'thinking'. This is the core of what makes your application. This can be much more than just database work. If your application is meant for calculating things, you should do that in your models. So not only crud should be in a model; the main 'thinking' of the application should be in there.
- Libraries are supportive to your application. The provide specific intellegence to do certain tasks. Look at the CI libraries. There is one that knows how to deal with ftp, one that know how to resize images, etc.

It can help to think of an analogy, comparing your application to a company.
- Controllers are like the management. The main course is decided here. The management tells the rest of the company what to do, what to send where, etc.
- Models are the factory. The real work is done here. If the controller says 'make 50 things' it is done here. If stuff has to be looked up from the warehouse, it also done here.
- Libraries are like specific departments. They assist the main workflow that goes on in the factory and can do some specialized processing. Like the painting department in a car factory. The car is built in the factory, when it needs to a be painted it is taken from the line into the specialized paint shop and then goes back.

I know this doesn't work all the way, but it does help, I think.
To answer your specific question: no, libraries shouldn't be looked at as 'subcontrollers'. Look at them as building blocks that do specific things. In many cases they can even be re-used in another project. For instance if you have a library that looks up a location in Google maps -- this is a task that you might use again in another project. By taking it out of the models, you make it easier to use that specific function again!

[eluser]Buso[/eluser]
[quote author="mddd" date="1275565781"]In the end it is up to you, but I think the general idea is this:

- Controllers manage the flow of what has to be done and what has to be shown.
- Models take care of the 'thinking'. This is the core of what makes your application. This can be much more than just database work. If your application is meant for calculating things, you should do that in your models. So not only crud should be in a model; the main 'thinking' of the application should be in there.
- Libraries are supportive to your application. The provide specific intellegence to do certain tasks. Look at the CI libraries. There is one that knows how to deal with ftp, one that know how to resize images, etc.

It can help to think of an analogy, comparing your application to a company.
- Controllers are like the management. The main course is decided here. The management tells the rest of the company what to do, what to send where, etc.
- Models are the factory. The real work is done here. If the controller says 'make 50 things' it is done here. If stuff has to be looked up from the warehouse, it also done here.
- Libraries are like specific departments. They assist the main workflow that goes on in the factory and can do some specialized processing. Like the painting department in a car factory. The car is built in the factory, when it needs to a be painted it is taken from the line into the specialized paint shop and then goes back.

I know this doesn't work all the way, but it does help, I think.
To answer your specific question: no, libraries shouldn't be looked at as 'subcontrollers'. Look at them as building blocks that do specific things. In many cases they can even be re-used in another project. For instance if you have a library that looks up a location in Google maps -- this is a task that you might use again in another project. By taking it out of the models, you make it easier to use that specific function again![/quote]

Sounds like models should me more application-specific, and libraries more generic, am I right?

But what happens with things like say, an auth system? It should be reusable, it must access the database, and probably it needs to handle sessions too.

I could do all that in a model, in a library, or a combination of both. What would you recommend. It would be reusable in every case, I can throw the auth_model in and that would be it.

[eluser]mddd[/eluser]

Sounds like models should me more application-specific, and libraries more generic, am I right?

Yes.

But what happens with things like say, an auth system? It should be reusable, it must access the database, and probably it needs to handle sessions too.

Unless your system is very specific to your application, that could (should) be a library. The tasks that library must perfom will probably be the same in other applications. Settings can be applied through configuration. Like accessing the database: the database access is set in configuration, so the library will function fine on another site with different database settings.

In fact, there are several auth libraries in use that you can take a look at. You wouldn't have to write your own. And the same goes for many other common tasks.

[eluser]Buso[/eluser]
[quote author="mddd" date="1275566566"]

Sounds like models should me more application-specific, and libraries more generic, am I right?

Yes.

But what happens with things like say, an auth system? It should be reusable, it must access the database, and probably it needs to handle sessions too.

Unless your system is very specific to your application, that could (should) be a library. The tasks that library must perfom will probably be the same in other applications. Settings can be applied through configuration. Like accessing the database: the database access is set in configuration, so the library will function fine on another site with different database settings.

In fact, there are several auth libraries in use that you can take a look at. You wouldn't have to write your own. And the same goes for many other common tasks.[/quote]

The model would work in any application too, it doesn't say anything about the database configuration.

[eluser]mddd[/eluser]
Technically yes.
But as you said in the beginning: models and libraries are not so different technically. The difference is more conceptual. A library is expected to be easily re-usable. A model is not. It can be very specific to your application. That's the difference.

[eluser]Buso[/eluser]
oh I see.. Thanks