Welcome Guest, Not a member yet? Register   Sign In
Grouping up functions for controllers and models.
#1
Question 

Let's say I have users and products. 

Users and Products both have profiles.

Let's just take basic CRUD functions into consideration.

Users can leave reviews(basic rating + comment) on user and product profiles.

This is where i am confused and indecisive.

Basically, i want a clean layout of my project because i can't deal with big pile of mess projects(ignites procrastination). An example of this would be to make only 1 controller file for all controller functions and 1 model for all model functions.

Now i have two choices, i can either break it up into 'purpose' or 'purpose+target', what i mean by this is.

'Purpose': create 1 profile.php file for controller and model and put all relevant functions inside those for both user and product.

'Purpose+Target': create 2 profile.php file namely, profile_user.php and profile_product.php and put all relevant functions inside both for user and product separately.

Which is better?

P.S. i'm a newbie
Reply
#2

(This post was last modified: 10-22-2019, 05:08 PM by dave friend.)

At each step of development, the question you need to ask at every turn is, "What is the main concern (purpose) for this class?". Where "class" and "file" are synonymous for our purposes here. In other words, we're talking about the concept called Separation of Concerns (SoC). (Also discussed here which also mentions the closely related topic of the Single Responsibility Principle.)

Using an MVC framework like CodeIgniter helps to maintain SoC to a certain degree. But, as you clearly understand, so does delegating responsibilities to the various pieces and parts. You cannot maintain SoC if you're trying to avoid a "big pile of mess" which I take to mean "a lot of files". The more focused any class is the easier it is to develop, test, use, and maintain. Tightly focused usually means lots of files. (It's not a bad thing - really!)

I tend to think of controllers as content displayed in the browser. IOW, almost every controller method generates output. So both users and products have at least one controller.

Models should be considered in terms of what data they handle and not which controller uses them. Any given model might be used by any number of controllers. There's no reason a controller cannot use more than one model. Come to think of it, there's no reason a model cannot use some other model. (Though that tends to indicate you sould use a common library.)

Speaking of which, don't forget about what CodeIgniter calls "libraries". These are just classes that are put in the /application/libraries/ folder. Many times a "library" will be the piece that provides logic needed by multiple controllers and/or models.

I'm not sure if any of the above fits into your concepts of "Purpose" or "Purpose+Target" but I hope it helps.
Reply
#3

(This post was last modified: 10-24-2019, 02:02 AM by dweenator.)

(10-22-2019, 05:04 PM)dave friend Wrote: At each step of development, the question you need to ask at every turn is, "What is the main concern (purpose) for this class?". Where "class" and "file" are synonymous for our purposes here. In other words, we're talking about the concept called Separation of Concerns (SoC). (Also discussed here which also mentions the closely related topic of the Single Responsibility Principle.)

Using an MVC framework like CodeIgniter helps to maintain SoC to a certain degree. But, as you clearly understand, so does delegating responsibilities to the various pieces and parts. You cannot maintain SoC if you're trying to avoid a "big pile of mess" which I take to mean "a lot of files". The more focused any class is the easier it is to develop, test, use, and maintain. Tightly focused usually means lots of files. (It's not a bad thing - really!)

I tend to think of controllers as content displayed in the browser. IOW, almost every controller method generates output. So both users and products have at least one controller.

Models should be considered in terms of what data they handle and not which controller uses them. Any given model might be used by any number of controllers. There's no reason a controller cannot use more than one model. Come to think of it, there's no reason a model cannot use some other model. (Though that tends to indicate you sould use a common library.)

Speaking of which, don't forget about what CodeIgniter calls "libraries". These are just classes that are put in the /application/libraries/ folder. Many times a "library" will be the piece that provides logic needed by multiple controllers and/or models.

I'm not sure if any of the above fits into your concepts of "Purpose" or "Purpose+Target" but I hope it helps.

What i meant by a big pile of mess is that a single php file(controller/model) having too many functions that are for different specific purposes.

I'll just give out a practical example. I'm developing an website for story sharing online. An example would be www.royalroadl.com where users can browse and read stories at the same time they can also upload their own so there's really no technical difference between a reader and an author.

Anyway, i have a story controller. I have all functions inside them that are related to my story like for publishing a new story, reading a story, bookmarking a story, liking a story, adding a new chapter to a story, i have a function that tracks which chapter a user has last read - last read function(chapter), BASIC CRUD functions.

Anyways, as stated above in my story controller, as much as possible i would like to separate the story functions from the chapter functions. So in short, i want to divide my current story controller into two - story and chapter controller wherein each controller handles their corresponding functions(story and chapter), so basic crud function for story would go into the story controller and basic crud functions for chapters would go into chapter controller.

I also forgot to mention that i still would have to divide the functions from private and public ones, private ones for those functions that require credentials(logged on user - creating a new story, adding a chapter[user must be author of said story], etc.) and public ones for not(like browsing, reading a story, etc.).

Is what i'm asking for logical in this sense? All in all, what i want is a clean project regardless of how many files it has wherein i just have to read their file names and function names for each file and i would already have a grasp of my project.

In essence, i basically just want to organize my project so it is readable. In light of this, i also avoid writing shorthand codes, i prefer the long ones like an if statement i would write out the whole if statement code or if using php in my html i would write the whole php code like <?php echo $name; ?> instead of <?=$name;?>

This is because i have other projects that i completely abandoned because i couldn't get into them after i stopped for awhile and have a look at my project that is messy(in my opinion) that i would rather restart the whole thing from the groundup than to continue them.

I would like to avoid the above situation.

I gave it some thought.

Although chapters are part of the story, if i think about it.

A story is a class of its own with its own attributes. While a chapter is a part of the story, it can also be a class of its own with its own attribute right?( i just remembered my OOP classes with parent class and child classes with inheritance, but this is Codeigniter, so i don't really have to do inheritance and what not, i can just create a different class(controller) for chapters right?
Reply
#4

(10-23-2019, 11:37 PM)dweenator Wrote: This is because i have other projects that i completely abandoned because i couldn't get into them after i stopped for awhile and have a look at my project that is messy(in my opinion) that i would rather restart the whole thing from the groundup than to continue them.

Smile We have all been there!

I have one hobby project that I have written and rewritten about five times now. Still cannot get it right.

The division of what goes in a model or a library, or what purpose your model or library is actually for, is quite an art form. Very much like database design. Get your tables wrong at the outset and your queries can become a nightmare. Get your libraries or models wrong, and your code becomes a mess.

In your example everything is part of a story, so your 'Story' library could contain everything. I would have a story library for creating new stories, getting stories, listing stories, etc. Anything at a 'Story' level. Then a chapters library for getting chapters for a story, adding chapters, reading chapters, editing chapters etc. Anything at a chapter level.

You could have a reading_library, an editing_library and a creation_library too. Then have a chapters model and a stories model that these libraries use.

There are lots of ways to do anything, it all depends on your plans and ambitions.

Good luck with it though, there is no 'right' answer.

Paul
Reply
#5

(10-24-2019, 04:10 AM)PaulD Wrote:
(10-23-2019, 11:37 PM)dweenator Wrote: This is because i have other projects that i completely abandoned because i couldn't get into them after i stopped for awhile and have a look at my project that is messy(in my opinion) that i would rather restart the whole thing from the groundup than to continue them.

Smile We have all been there!

I have one hobby project that I have written and rewritten about five times now. Still cannot get it right.

The division of what goes in a model or a library, or what purpose your model or library is actually for, is quite an art form. Very much like database design. Get your tables wrong at the outset and your queries can become a nightmare. Get your libraries or models wrong, and your code becomes a mess.

In your example everything is part of a story, so your 'Story' library could contain everything. I would have a story library for creating new stories, getting stories, listing stories, etc. Anything at a 'Story' level. Then a chapters library for getting chapters for a story, adding chapters, reading chapters, editing chapters etc. Anything at a chapter level.

You could have a reading_library, an editing_library and a creation_library too. Then have a chapters model and a stories model that these libraries use.

There are lots of ways to do anything, it all depends on your plans and ambitions.

Good luck with it though, there is no 'right' answer.

Paul

Your answer has enlightened me.

I already knew from the start that there were no 'correct' answer to my question, i think i've asked this question once on stack and i got downvoted so hard there.

Anyway, i personally haven't tried making my own custom library so i will just divide my controller onto what i have originally in mind( story controller for anything story and chapter for anything chapter).

Once i'm done with this i'll explore onto the other ways you have suggested starting especially with making my own custom libraries. 

I think that's an integral part to codeigniter. Being able to make your own library and/or helper.

For example, i could simply make my own account library for everything related to it(creation,validation, etc.) and reuse it on all my projects. Possibilities are endless.

Thanks.
Reply
#6

Hi,

That is exactly what I do. I have a membership_library for authorization and authentication, a user_library for user profiles and user details etc, a thing I call my functions_library with lots of useful (for me anyway) date and time manipulations, and a layout_library I use for outputting views and templating. I use these on virtually every project I do - they are so useful.

CodeIgniter is fabulous.

Best wishes,

Paul
Reply




Theme © iAndrew 2016 - Forum software by © MyBB