![](https://csdnimg.cn/release/download_crawler_static/10788824/bg10.jpg)
Where Does This Go? 3
“Wait!” I hear you yelling. “This is supposed to be OOP programming. What gives?!” First, nothing
will ever be 100% object-oriented. You always have to have your bootstrap file that runs through
and instantiates all of the needed classes. So forget the idea that you’ll ever get rid of procedural
code and functions. It’s a lie.
Helpers, then, are used to provide new functions that can be used easily to provide custom
functionality. You can use these functions to provide compatibility functions for when the command
doesn’t yet exist in your version of PHP. They can be used in form validation callbacks to provide
custom validation methods. They can also be used to do some simple or common formatting
within views since, once loaded, they’re always available. You’ll also find third-party code that
is implemented as a function that you want to use. A common example, for me anyway, is the
Markdown Extra libraries. For years I’ve used those, though I’ve recently switched over to the PHP
League’s CommonMark libraries. (No, I didn’t switch because it was an OOP solution.) The fact is
that functions still have their place, and helpers provide a simple way to load them. Simple as that.
Libraries
Libraries were EllisLab’s way of making it easier to load any class that was not a controller or
model. This was before the days of namespacing and good autoloading in PHP. Libraries can be
used to incorporate third-party code, though more often than not, you’ll simply use autoloading
and won’t need anything special for third-party code.
Libraries can be used to provide common functionality that you want accessed by different
parts of your app. They help provide a single point of entry that makes it simple to maintain
consistency in business rules. They’re ideally used for creating focused, single-responsibility classes,
like Benchmarking, UserObject, Article, etc.
The thing I want to emphasize here, though, is that they were the way to handle any class that was
not a controller or model. I think this is a very important concept when using CodeIgniter so that
you don’t paint yourself into a corner when it comes to using other classes. Libraries are not just
a file that must contain stand-alone information that can be passed from project to project, though
that is the traditional role in CodeIgniter applications. It’s just not the only use for libraries. Many
new paradigms are becoming common in PHP programming that have come from more traditional
software development. You can now have Entity Models, Factories, Adapter classes, Decorators, and
many other classes that help fulfill different design patterns. The one thing they all have in common
is that they are a class. In CodeIgniter, the only way provided to load these classes is as a library. The
other options are to hardcode require statements or use an autoloader like Composer. Personally, I
highly recommend Composer, and will discuss that more in a later chapter.
Earlier, I said I’d make a case for splitting the business logic across Libraries and Models. Let’s tackle
that now. The more I work with CodeIgniter, and PHP in general, the more I find situations where
following this simple rule of splitting it into two layers would have saved me time refactoring. So,
to save you that time, here’s the primary reason I recommend splitting them up. Depending on how
you structure your app, you might find other benefits along the way.