Examples of using the Model class?

[eluser]Doug Lerner[/eluser]
But with regards to the Model "representing your data structures", that's the part I'm not quite following in CI.

In Rails, for example, the Models section specifically does represent your data structures. The actual structures. The tables and fields are defined there.

But in the CI examples I've seen so far, the Models area seems to just be a collection of helper functions for doing operations on the database. In other words, it looks more controller than model.

Am I just missing something? I admit I am a complete newbie at this, so please don't hesitate to call me an idiot and point out what I am missing! But I am not see where in the CI Model area "representations of your data structures" are defined.

Thanks,

doug

[eluser]Colin Williams[/eluser]
CodeIgniter is not Rails. Models in CI don't support the same features as Models in Rails. Rails has built in ORM. CodeIgniter does not.

[eluser]Doug Lerner[/eluser]
[quote author="Colin Williams" date="1215583064"]CodeIgniter is not Rails. Models in CI don't support the same features as Models in Rails. Rails has built in ORM. CodeIgniter does not.[/quote]

Just for my own understanding, is it fair to say that CI is more of a CV framework than an MCV framework?

I see how the controlling logic is very nicely separated out from the views, which is very useful and important. But since the docs say the Model part is "optional" and since the Model part seems to be basically more controlling functions, is it reasonable to think of CI as really being an CV framework?

Thanks,

doug

[eluser]Colin Williams[/eluser]
It is what it is. MVC, CV, AC/DC.. whatever you want to call it or it wants to call itself. The use of Models in CI can merely be seen as logical separation (otherwise known as organization).

From the user guide:

Models are optionally available for those who want to use a more traditional MVC approach... Models are PHP classes that are designed to work with information in your database. For example, let's say you use CodeIgniter to manage a blog. You might have a model class that contains functions to insert, update, and retrieve your blog data.

[eluser]Doug Lerner[/eluser]
Not to belabor the point... But I just watched Derek Jones' "blog in 20 minutes" video tutorial and he put all the database-related functions right into the blog controller class and didn't even bother going into the model area at all.

And that certainly seemed convenient.

What I don't see is any benefit in the CI framework of doing what he did in the Model area instead, because the Model area really isn't doing anything "model-like" such as defining the database schema or anything, right?

doug

[eluser]Colin Williams[/eluser]
Derek's example made, what, 2 queries in total. I find that as the complexity of the app grows, it's nice to have the model class as a nice separation and abstraction of common queries. You are right, CI models don't do ORM, define schemas, or anything like that by default. CakePHP or Symfony might do something like that, if you care for the additional overhead of those frameworks.

[eluser]Chris Newton[/eluser]
The benefit of using models is that

1. you can use your database functions in multiple controllers (easily) Controllers shouldn't really call functions within other controllers, so you need a place to put your database calls that is not inside a controller (if you plan to have more than 1 controller).

2. You can load models into libraries. Libraries shouldn't load a controller, so it's better to have your database calls in the model. It's not a best practice to load a library or model in a library either (for portability purposes) so that point may be moot.

3. Models can't be called directly from the web, so it might aid your security setup. You can use _functionname in a Controller to limit external access to a function as well, so it's only a minor point.

If you choose to do so, the model can be doing something 'model-like' which is to store the functions used to control data flow into and out of the database, the business logic of the application. The developers of Rails have chosen to use ORM, which does not necessarily define the value of using a model in itself. Long before ORM, the MVC design pattern was outlined, and for years the M has been an abstraction that existed because it's handy to separate business logic from application function. In my experience it's been very useful to collect all of the database calls in a separate entity, for maintenance, multiple point connectivity, and portability. As you mentioned above, I've created functions within some of my models to auto-create tables if they're not found with an initialization function, which makes reusing some common-themed models a simple operation (like users models, etc)

To sum up. You don't HAVE to use the MVC pattern. The model's purpose is to contain business logic and interact with the database. ORM != Model though...

[eluser]Doug Lerner[/eluser]
Thank you, Mahuti. You made some very interesting and useful points there.

I am still "wrapping my head around" the use of a framework. I never have used one before before. Even though I've done extensive server-side development (using a different, proprietary object oriented language and object oriented database) all my code really has been all mixed up - never separating out the main logic from the views. As a result, designers have always found the applications I developed hard to customize.

So one main goal in moving into a framework is to separate control from view. That seems straightforward in CI.

I was really interested in separating out the model also. You have pointed out some immediate benefits, such as re-usability in different controllers.

The only thing I would really like to figure out now is the best way of dealing with the storing and retrieving of object-oriented data. The last system I used had a built-in object-oriented database and there were no tables to set up. You simply created objects and stored them and referred to their properties and modified them as needed. You basically never needed to touch the database.

In CI it looks like I will probably have to write my own helper functions to accomplish similar ease-of-use of objects. I use a lot of objects, and don't want to spend all my time defining SQL or manually creating tables to define each one!

Thanks,

doug

[eluser]Chris Newton[/eluser]
Since the web is 'stateless' you kinda need some kind of storage mechanism if you're going to be playing with large amounts of data. You could write the data to pages or caches to store & access with a session variable, but I imagine using a database would be faster.

[eluser]Doug Lerner[/eluser]
[quote author="mahuti" date="1215673702"]Since the web is 'stateless' you kinda need some kind of storage mechanism if you're going to be playing with large amounts of data. You could write the data to pages or caches to store & access with a session variable, but I imagine using a database would be faster.[/quote]

Oh, for sure I want to store my objects in a database!

I just want to figure out the best way of doing it without spending all my time writing database methods and manually updating the database to handle new tables and columns, etc.

Just as a for-instance:

In the proprietary system I've been using (which used server-side JavaScript and a proprietary object-oriented database, non-SQL), if I wanted to add a new user property I could just say:

theUser.someProperty = whatever;

This would store the value of whatever in the database in the user record. I didn't have to set up the "someProperty" property in a table anywhere. And the value of whatever could be a scalar, an object, an array, an object containing arrays containing objects - anything.

I am wonder what my approach has to be in CI in order to accomplish something nearly as simple?

If I wanted to add a new property to a user record it seems I first have to do some database twiddling in order to make sure that the user table has an entry for "someProperty".

And if the value of someProperty is anything other than a scalar value, I have to do what? I'm not sure yet. I suppose I could serialize the value and store it that way. Otherwise I have to add more tables to represent the object that is being stored and link it in somehow, right?

What I want to do is move into open source development where there is a larger developer and customer base and better "future proofing". And I want to move in MVC so I can easily separate out my business logic from views.

But I also want the ease of being able to work with possibly complex objects and just store and reference them and retrieve them at will without spending a lot of time having to fiddle with the internals of the database every time I want to add a new property to an object or add new objects, etc. In other words, I want to think about my application higher-level logic, and not spend my time thinking about the low-level details of how the data is stored internally.

That is the part I'm stuck on.

I'm an experienced developer - but unfortunately not experienced with SQL or PHP frameworks. I've been in my little developer cave using this special proprietary development system for a few select customers for 8 years and now want to work more in the "real world". But I'm finding going from straightforward object-oriented development, including the storage of object-oriented data, to the existing frameworks a learning curve. It seems that "ORM" is the way frameworks deal with the particular issue I'm talking about, right?

Thanks!

doug