design pattern question

[eluser]llbbl[/eluser]
Are libraries considered part of the 'Model' pattern strictly speaking. I know models are meant to be used in a different way than libraries in CI, so that is not what I am asking.

I'm saying if you used libraries, controllers and views can you say you are also using the MVC pattern?

I think there is a lot of confusion about design patterns. Hopefully a comp sci or soft eng major can provide some enlightenment.

[eluser]Pascal Kriete[/eluser]
I would consider libraries part of the business logic, so in that sense they're controller components.

More correctly though, I see them as part of the framework. MVC is an organizational pattern, but commonly used functions and classes still need to be seperated. A framework isn't just 'MVC', even if that is the buzzword these days.

In the core CodeIgniter uses other patterns as well. The loader is a singleton interface, form validation is a strategy pattern, the database drivers use an adapter pattern, etc. Design patterns aren't set in stone - it's not an all or nothing approach. It's useful to know a few by name, so you can quickly describe a design approach without going into the details. They work roughly the same in most higher level languages, so you can tell a Python guy how your PHP application accomplishes feature X using just two or three words. But then, I learned most of them from a javascript book, so what do I know .

Let's wait for Mr. Casburn to get here.

[eluser]llbbl[/eluser]
I happen to have a copy of 'design patterns' gang of four, book that I bought because my roommate was taking the class, back in like 1999.

quote "MVC uses other design patterns, such as factory method to specify the default controller class for a view and Decorator to add scrolling to a view. But the main relationships in MVC are given by the observer, composite and strategy design patterns."

they are using it in smalltalk as the example.

earlier in the section

quote"The model is the application object, the view is its screen presentation, and the controller defines the way the user interface reacts to the user input."

So based on that I'm thinking that some libraries CAN be thought of as Models. Say you have a ACL/user admin library and a function that checks if the user is logged in or not. Then in your controller you have something like if(!$this->acluser->login()){redirect("/", refresh);}.

The controller is defining what the user sees, the application logic is definitely the function in the library and of course the view is HTML (screen presentation) that the user sees. It meets the definition of MVC to me, doesn't it to you?

[eluser]xwero[/eluser]
A library is a tool to speed up your development and it should be build to add to every organizational pattern. So a library is not a part of the MVC pattern but you can build it to take advantage of an organizational pattern.

The problem with some libraries is that they are too tightly coupled with an organizational pattern because they are build when using a particular pattern. As for the ACL/user admin library IMO it's more a module than a library because you have models, views and controllers and then there are methods of the module that are used in other controllers and views.

[eluser]esra[/eluser]
Generally, design patterns are rough guidelines for getting something done and are not necessarily unique to software development. In fact, they were originally developed by an architect to document various approaches for building design. You use design patterns in your every day thought processes or as a matter of habit without knowing it (e.g, wake up in the morning, have a cup of coffee, drive to work, work all day, drive home, have dinner, go to bed, then repeat the pattern on your next work day).

If you want to learn more about design patterns from a PHP standpoint, you might want to visit this site:

http://www.fluffycat.com/

For a good book relevant to PHP, take a look at "PHP Objects, Patterns, and Practice" by Matt Zandstra, Apress.

Regarding the Model within the MVC architecture, the /system/libraries/Model.php file is a library and the models for your MVC triads are extended from that library. Libraries are designed to be resuable objects. The models for your MVC triads usually include unique code with business logic dedicated to their respective MVC triad but they also inheirit the functionality of model.php.

However, there may be cases where you want to globally replace the behavior of Model.php. You can do this by replacing Model.php with another file of the same name stored in your /application/libraries/ directory. In this case, CI will load your model.php instead of system/libraries/model.php. You can also create other model libraries under other names and store them in /application/libraries/, then extend from those model libraries. For example, all of the third-party ORM libraries for CI use this approach.

In CI, it's also possible to extend a model residing in application/models/ to create a new model also stored in the same directory. For an example, take a look at the Nested Sets contribution on the wiki.

[eluser]Randy Casburn[/eluser]
@llbbl - I can't write short posts - ask wiredesigns! May I add just one little point?

The thing that is missed throughout this particular community - that frustrates me personally- is that the M & V & C are constructs. As you so duly noted, these constructs are made up of other design patterns. This community, CI, completely neglects the design patterns within the design patterns. There is little talk of observers, adapters, builders, decorators, etc. that it takes to make a C or a V work for instance.

But to your point...If you flip a couple more pages to section 1.3 on page 6, you'll see how design patterns are supposed to be described. As esra so eloquently pointed out, when MVC is put together in this fashion and described as a design pattern, it becomes a rough guideline for getting web applications built with CI. So given this logic, libraries are not part of and design pattern.

Think of if this way. When an architect wants to design a skyscraper, they don't have the luxury of putting together the real thing, tearing it apart and putting it back together again. The best they can do is simulate these things with plastic or balsa wood. The design pattern provides them a way of visualizing how it will all fit together.

That's all it is supposed to do for us too. As coders, we make the mistake of sitting down at the keyboard and we put steal beams together. After it is all put together, then we try to cram it into the design pattern. We go about things differently than was imagined.

I'm not sure, but maybe that's why your brain hurts over this. Try to sit down with a piece of paper and a pencil. Think about your design and the patterns with those tools first. If your first thought is what code do I write first, a Model, View or Controller, because that's the design pattern, can you see where, from an "architects" point of view, you've kind of gone all wrong?

You may work for a software architect some day. Trust me on this. This is the way they think.

Randy

[eluser]Unknown[/eluser]
The singleton pattern deals with situations where only one instance of a class must be created. Take the case of a system administrator or superuser. This person has the right to do everything in a computer system. In addition we will also have classes representing normal users. Therefore we must ensure that these classes have no access to the super user constructor. The solution to this problem in C++ and Java is to declare the superuser constructor private. The superuser class itself has a private static attribute sysadmin, which is initialised using the class constructor. Now we get an instance of the super user class with a public static method that returns sysadmin.

----------------
Nikimathew
buzz marketing