Passing a single array to a model

[eluser]xwero[/eluser]
I think you first need to sit down think about the data you need, then think about how you need the data and then start to create models. It seems you dive in an application head first.

[eluser]TheFuzzy0ne[/eluser]
[quote author="xwero" date="1236714934"]It seems you dive in an application head first.[/quote]

Guilty as charged! I tend to think about the layout first, and then create models methods to pass back the data I need. Then I end up with a bunch of model methods that do a very similar thing, which leads to my original question. Maybe I should be thinking about models before anything else? I've learnt that when I am planning an application on my own, no matter how well I plan, there's always something that gets in the way, be it an oversight, or the client changing their mind. So now, I tend to build an app one piece at a time. I know the result I want, and I build my application around this requirement.

If you can find the time to answer this next question, I'd appreciate it, but don't worry if you can't. I understand it's a very complex question and may take time to answer. Let's say I was to build a forum (which I will need to do soon), how would you plan it? Would you start with the model? If so, what model methods would you use. Obviously there would be methods like get_forums(), get_categories($forum_id), get_threads($category_id), get_posts($thread_id), but how would you handle something like say a search, where that can be several arguments, such as member name, forum/forum category, results per page, key words/exact phrase, start result etc... Would you just have a function that accepts 6 arguments or more, or would you take a different approach? For me, it makes sense to perhaps pass in a single array/object, with the search parameters, but then I start to think "Why even bother with a model when I can easily build my query within the controller?".

Hope this make sense, and thanks again for your time. Again, if you don't have time to answer this question, I totally understand. The again, perhaps the answer is more simple than I thought.

[eluser]xwero[/eluser]
It's very tempting to add the queries to your controllers but i think it's a big mistake. Not only because of the MVC structure but because after a while you find yourself copying the same code in different controllers.

The application planning i use is

- get as many input on how the client wants the application to look like, how it should function, what kind of data needs to be manipulated visually
- figure out how much data you need and where you are going to put it
- check which code you can use that is already made
- create wire frame methods and files you think you are going to need, this means controllers ,models and views
- build section by section filling up the methods and files with actual code.

Between the last two steps you can write tests to automate the testing of your actual code.

To summarize : don't focus on the actual code but try to see the big picture when you are writing code.

Of course this is without considering the economic side of creating an application.

[eluser]TheFuzzy0ne[/eluser]
OK, and how would you handle something like say a search, where their can be several arguments, such as member name, forum/forum category, results per page, key words/exact phrase, start result etc... Would you just have a function that accepts 6 arguments or more, or would you take a different approach?

[eluser]xwero[/eluser]
Lets take this forum as an example. You have the search box at the top of the page and you have the advance search.

I would make two methods because the search box looks in the titles and the posts for all words in all forums. This is a pretty expensive query. The advanced search can be limited much more than the search box query so the method should make this possible. You could build the search box query in it's own method and use the advanced search query to fetch the data but i think you can optimize the search box query better in it's own method.

[eluser]TheFuzzy0ne[/eluser]
OK, I think the way I'd implement it would be to pass the $_POST array over to the model (after sanitizing, it of course), and then have the model check for various post values, and build a query that way.

This would mean that the query would only be as expensive as it needed to be, based on the variables supplied to it (which are pretty much all optional). I would probably use a single model method, that accepts an array as the first parameter (containing the post array), and accepts an additional second parameter, which will search the title only (which would default to FALSE).

Basically, I think that where many optional parameters may or may not be specified, it's probably best to pass an array over to the model method, whereas when a specific, smaller number of arguments are required, I'd use individual parameters in the method declaration. How does that sound?

[eluser]jedd[/eluser]
Going back a step (and then I'll get to my take on the design approach)

[quote author="TheFuzzy0ne" date="1236710590"]
Indeed. I just want to avoid repeated code as much as possible. For getting a rows by ID or by Email, or by username for example, the code in each function would be virtually identical, apart from the WHERE condition.
[/quote]
Yes, but each function is then insulated from any changes you may make to that function in the future. Sure, you probably won't, but that's not the point with coding for tomorrow, is it?

As you say, these are perhaps three lines of code - two of which are rough validation and a return() - but there's still the possibility that you'll make this more complex in the future, perhaps as your schema changes.

(Random example - consider what happens if you properly normalised the average 'user' table. For most programmer-designed systems this would mean that you'd then be looking up a different table for a user's name, f.e. - and if you're doing AR this means a different model. If you've got specific get_by_XYZ() functions, this is relatively easy to migrate to. If you don't, you can fake it but you'll be doing some ugly stuff to make it happen.)

As to how far you take this - it's obviously a matter of degree. I like the idea of sticking to multiple simple clearly labelled function calls - but that's because a) I won't have an onerous amount of them, b) they don't take up much space (and are bundled neatly together in one section of my model), c) there'll be no chance of them being a measurable performance problem, and d) I'm not a terribly proficient or experienced coder so I like the added reassurance that it'll make my code easier to read in the proverbial 'six months from now'.

It's also safe to say that making these more abstract later on will be easy, as I can search for each specifically named function call and migrate it to any new generic call, if I ever feel the need. Going the other way will be less easy, as I'll be searching for a generic function call with any number (and named) parameters.

So, no, I don't think this approach engenders consequent problems down the road - I actually think it'll insulate you from some.

Personally, I think that would complicate things as you may not know for sure if you're accessing the right "version" of a particular function.

I kind of like the idea of function overloading, when I read about it a while back in an OO theory book, and was then a tad disappointed that PHP (incl. v6) doesn't offer it. I can see the benefits of the feature, but OTOH I also feel safer knowing exactly what I'm passing and what I'm expecting at the other end. I suspect a lot of that is attributable to (d) above though.


To the question of designing a forum .. xwero's approach is far more formalised than what I do (I have a very jedd hoc approach to design - much like you described your approach). If I was trying to be a bit more disciplined I'd probably approach it from a data dictionary / ERM angle to start with, and then work back up to some very basic models. If you're committed to AR then you're committed (IIRC) to a single Model per DB Table, anyway. Things like your search function would probably get designed after (and here I'm echoing xwero) you've come up with some mock-ups of screens. So in that sense I suppose I'd be designing from both ends - the stuff under the hood that I just know will have to be there, the basic infrastructure stuff I suppose. And the other side - the UI side - either based on 'competitor analysis' or user requirements. This falls down when the user is your own imagination though!

[eluser]TheFuzzy0ne[/eluser]
Wow! Interesting read. I agree with pretty much everything you said. I guess the key is not necessarily to worry about DRY, but instead to be more concerned about KISS. My programming style is similar to XP. I do things iteratively, so I guess that the first thing I should so is have everything working as simply as possible, and not get too hung up on the details. Keeping things simple also makes it easier to change things as often as the client changes their mind.

Thanks for the book, errr... I mean your comments.