[eluser]jedd[/eluser]
.. no, not the title of a supplemental from a hollywood men's magazine.
Here's the thing. I've written a model - called Member - that will front all my user related tables in the DB. I created the class Member with a bunch of attributes - variables that are specific to that object (I'm spelling this out in case I'm using the wrong terminology somewhere) - before the constructor. This includes a bunch of easy stuff - eg $id, $first_name, $admin - as well as things that take some effort (come from multiple tables, require COUNT's, etc) to calculate.
I envisaged that within the model, I'd have a method called authenticate($user,$pass), say, that after verifying a user's credentials would call a private function, say _populate_self() that would fill in all the object's attributes. Subsequent hits to the model via attribute references (eg. $this->member->firstname) would retrieve from this attribute, which obviously wouldn't involve any DB hit. I like this idea, and it sat well with my understanding of how objects should work.
When I want to look up any details about a different user (to 'me') I'd instantiate a new model - Member($someone_else_id) - and away I'd go. So on a page like the one you're looking at now, f.e., there'd be up to 10 Member objects created and destroyed, as I instantiated a new one for each message author and grabbed their number-of-posts tally, login_handle, and so on.
Though this seems expensive, there's no way around the fact I have to hit the DB to get those data. And I assumed that creating and destroying the objects, even CI Model objects, is not onerous.
Now, from nuances in other threads, I'm getting the hint that this is not the way most people use (or would recommend I use) a model. The model should be seen more as just a library of related calls to the database, rather than an object in the classical OO sense.
So, the question is this - what am I missing?
[eluser]Colin Williams[/eluser]
CI describes Models as "PHP classes that are designed to work with information in your database." I'd say that answers your question. But even though this is how they see you using models, there is no reason you can't use them in the way you formerly proposed.
And to your nervousness about database calls, it's best to start off by simply following the rule that similar queries should not be made more than once. Then when your app fulfills all of it's requirements, go back and look for ways to optimize your database interaction.
[eluser]TheFuzzy0ne[/eluser]
[quote author="jedd" date="1237223767"]I envisaged that within the model, I'd have a method called authenticate($user,$pass), say, that after verifying a user's credentials would call a private function, say _populate_self() that would fill in all the object's attributes. Subsequent hits to the model via attribute references (eg. $this->member->firstname) would retrieve from this attribute, which obviously wouldn't involve any DB hit. I like this idea, and it sat well with my understanding of how objects should work.[/quote]
May I suggest you use a public "initialize" function instead? Then you could add a simple "is_logged_in" property, or something similar.
[quote author="jedd" date="1237223767"]So, the question is this - what am I missing?[/quote]
Nothing. There's no single way to implement a model. It's up to you, the developer, to implement it in a way that suits what you need it for. Why not have two models, one containing a method that returns all of the user rows, and one that can be passed a single user row, and instantiate itself from the data within it? It's probably overkill, and I doubt I'd do that, but if it works for you then why not?
My question is, do you really "need" an object for each user? It sounds nice, but sounds like it's gonna be a PITA to implement. If you really want to use your model as an object, why not make it an object that represents a "group" of users?
[eluser]jedd[/eluser]
So .. reading between the lines here, you guys wouldn't use any attribute data in this way, inside a model object, is that right?
[quote author="TheFuzzy0ne" date="1237225891"]
My question is, do you really "need" an object for each user?[/quote]
Well, if I want to sleep at night, sound in the knowledge that I'm doing things the OO way .. yeah, definitely.
I'm not overly fussed, of course, about the OO way. And reading the CI manual it looks like they never intended it to work this way either - as per Colin's quote about the intent of the model (not that that section of the manual precludes using the model as a OO type Object, mind, but it's not exactly encouraging you down that path).
Quote: It sounds nice, but sounds like it's gonna be a PITA to implement.
I suppose part of my question back at you would have to raise the question of performance comparisons, though in this instance it'd be pretty hard to measure - indeed it would be hugely reliant on the eventual structure of my code. Again, going back to Colin's comment, just keeping the minimise-your-db-calls goal in mind, would probably result in similar performance at the end of the day, regardless of which of OO-object versus CI-object approach you followed. I'm pretty confident that creating new model objects (if I could even find in the guide again how this is done) is inexpensive, compared to the cost of a couple of dozen DB calls.
Okay -- I'm going to succumb to peer pressure, I think, which will keep my code aligned with everyone else's, as well as keeping it aligned with all my other models (which definitely work in a CI-object way), and treat it as just an interface to one part of my DB.
[eluser]TheFuzzy0ne[/eluser]
One more idea which I was kind of hinting at, but not thinking through fully. You could have a factory. The factory would do a single query for the specified rows, and pass back an array of user models for you to do as you will. I thought it might be a problem when it comes to updating the user data in the database, but to my knowledge, you'd have to do each update as a single query anyway. However, with my method, say you got the data for 10 users, it would save you 9 select queries.
[eluser]Colin Williams[/eluser]
If you look at all the CI examples, all the CI libraries, and even chunks of EE code they have shared, I think you can absolutely conclude that they have designed CI to act one specific way. We know this does not rule out doing it the $obj = new Obj() way either. So take a direction and be consistent and you'll be all set
[eluser]jedd[/eluser]
Quote:You could have a factory.
I'll have a read-up on what that would entail -- I don't know much about the practicality of factories, but whenever I hear the word used in the software construction sense, I am reminded of [url="http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12"]that classic Joel rant from a few years ago[/url].
[eluser]Colin Williams[/eluser]
Sounds to me like one more metaphor to throw on the pile. I've made sites/applications in CI with large numbers of users and lots of user functionality and one "user" model has always sufficed. Always look at your app in the simplest of terms.
[eluser]TheFuzzy0ne[/eluser]
Interesting rant. 
[url="http://en.wikipedia.org/wiki/Factory_method_pattern"]Factory Method Pattern[/url].
|
