design philosophy: helpers,libraries, and bears oh my

#1
[eluser]fivestringsurf[/eluser]
This is NOT my first week using CI and YES Ive read the documentation (flow chart, mvc, helpers docs., etc...)

I just wanted to get some feedback on some of you more experienced developers on how you choose to separate your code. It seems I get stuck between what becomes a library and what becomes a helper(amongst other things). I keep redeveloping my work and keep switching reasons to do so...sometimes even models get dragged into the confusion.
------------------------------------

Right now here is how I choose my separation:

Libraries: Anytime I am extending CI core /or/a large class of my own such as login/log out routines.
Helpers: Things that I would normally use "include()" for. smaller code for say an html form that I use repeteadly.
Models: database connectivity divided up into C.R.U.D folders I try to have all my models simply return the object they fetched and nothing more...that makes my controller have a bit more code/formatting results but I always know what to expect from the models.

---------------------------------------
I try to have all calls to models,helpers, and libraries from controllers only; that way I know where everything is coming from and don't have to chase down functions/methods; the only exception would be with one of my large custom libraries. It makes each controller a bit with conditionals (ifs/switch/etc...) but it becomes easier to read the code.

I noticed ci2.0 also has a "third_party" and "core" folder just to add to the perplexity.
----------------------------------------

I would appreciate some conventional wisdom in these regards.
What are your rules for separation?
helper: ?
library: ?
model: ?
???

#2
[eluser]n0xie[/eluser]
This is how I see it.

Helpers
Standalone functions (or static classes) that change some output in some way. Either by re-ordering data, transforming data, or styling data.
Example: site_url() : adds the the domain name to an url if it's not there

Library
(Standalone) Classes that are usually not application specific.
Example: Message Library: a class that takes care of displaying messages to an user

Models
Data Abstraction Layer that is usually application specific
Example: Page_model: contains and encapsulates your page logic and a way to access the persistent store (usually a db)

#3
[eluser]fivestringsurf[/eluser]
I like that you mentioned "libraries" are NOT application specific...that's a great way of looking at it... but what about when they need db connection? Do you make your db calls from right inside the library?

#4
[eluser]n0xie[/eluser]
You can easily grab the CI superobject from inside your library and do you db stuff there. Just make sure you mention in the DOCS that the class/library is CI specific.

In this example the Message library is CI specific, but not application specific.

#5
[eluser]fivestringsurf[/eluser]
by grab the superobject...do you mean something like this:
$CI =& get_instance();
And yes ...never under estimate documentation!

#6
[eluser]InsiteFX[/eluser]
Yes thats the CI Super object.
Code:
class Someclass {
    
    private $CI;

    public function __construct()
    {
        parent::__construct();

        // get the CI superobject!
        $this->CI =& get_instance();

        // now you can use $this->CI-> to get database etc.
    }

}

InsiteFX

#7
[eluser]fivestringsurf[/eluser]
thanks for the input n0xie & insiteFX


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.