I'm building a small little CRM type app for my brother's company as a Laravel learning exercise. I really like what I've learned from this framework so far.
I have a Deal model that has a couple of boolean attributes, for_management and for_admin. My User model also has is_management and is_admin boolean attributes.
My main route to show the deals right now is returning all deals, but of course I want to only show the deals that are relevant to the user. A user might be both management and admin, so not sure of the best way to structure that logic.
Feels like I don't really want that logic to exist in the controller and might be better being defined in the User?
Scopes are another thing I've been looking at, but it doesn't feel like it would be "the right thing".
What would you suggest?
Related
I have watched many youtube guides/tutorials but those only tackle the coding part.
Whenever i start a project, i always start with a simple controller called main.
and 2 models.
For example: if i were to start an online store project. Then my models would be 'product_model' and 'user_model'. All database functions for users, i always put them in the 'user_model' and all database functions for products, i always put them in the 'product_model'.
user_model:
public function register(){
}
public function login(){
}
//more functions for user
product_model:
public function create_product(){
}
public function review_product(){
}
//more functions for product
My problem is that i easily get confused with my project and/or dissatisfied with how unorganized it is. especially when im more than halfway into the project and i accumulate hundreds of lines of codes.
I could try to organize them myself but at the end of the day, i'm just an amateur so i end up doubting myself. so i get no work done for 1 day(or doing work but redoing it again and again). then that snowballs to tomorrow and the day after that and so on and so forth.
So i want to ask to experienced programmers a basic guideline for me, when to create a new model and a new controller?
How do i group up functions and make them into a separate model?
Do i make a new model per table? and all database functions to that table i just write in the new model created for that table?
Or
Do i group up database functions based on what they do? for example: purchasing a product involves many separate database functions. so save them all inside purchase_model?
The answer to all of these questions is: it depends. Personally I think that kindof of flexibility is what makes coding so interesting.
As a general rule of thumb I try to keep all my classes less than 500-700 lines of code and functions less than 20 lines of code. If my class becomes larger than that I usually start a new one. With that being said, controllers I am fine with being larger as form validation and response logic can take up quite a few lines.
So let's take an example: user authentication system
I would have a controller that contains functions for login, registration, forgot password, and activation; another controller for user management that contains functions to delete, ban, unban, activate, and create new users; and then another controller for the users' profile that contains functions for editing their details and profile picture.
Now as user management and auth systems are typically reusable a library is better then using a model or models; but let's say we use models. I would have a model for each of the controllers outlined in the aforementioned paragraph and then a model for general "utility" functions like checking if the user is logged in .etc.
Generally
You have to decide:
How much code is too much for a controller/model?
(with above) Do I expect my code to grow? If so then I have to take into account how much when determining (1).
How should I group together functions? For this keep in mind separation of concerns e.g. auth functions shouldn't be grouped with database backup functions.
Am I doing too much in a particular function/model? If so, how should I separate these items so that I conform with DRY principles (chances are some code is reusable elsewhere even though its functionality is inherently different).
(with above) If this code is really that useful elsewhere, should I make it into a library/helper?
(and there are countless other things to take into consideration).
I think it is important to realize (especially as a beginner) that your coding style and the "techniques" and organization skills you use will be constantly evolving and so will your code. While it is nice to see that you want to learn the best practices - a lot of this will be dependent on what you want to achieve with your app and what level of mastery you are at in your coding career. Try and look at the bigger picture and realize in a year or two when you look at your code again you will probably say "what was I even thinking here?".
Side note: you could research the ORM approach to models (Laravel and a host of other frameworks use it) but CI has a more "whatever" approach to just about everything. If being forced to work a certain way makes you feel more secure, you might want to learn other "more advanced" and "newer" frameworks.
I'm still learning Codeigniter/PHP/Database/SQL.
Whenever i encounter new problems, i usually learn something to solve them that may/may not apply to my previous methods.
If they do apply to previous methods or if i make changes to my database design, i usually have to edit/update my CRUD methods relevant to the tables changed.
The problem lay there, since i write my methods as i need them and i don't follow any plan so they're all over the place.
It's not that its not solveable but its very hassle and it just saps away any anticipation i had towards improving my codes then i end up just doing other stuff(procrastinating), its a very vicious cycle, whenever i try to get into it, i end up procrastinating then days pass by then weeks.
I also want to implement thin controller/fat model idea ive read online. Up to now, this is also a part of the problem. I'm trying to solve them all right now but i have a question/doubt before i can truly do it.
I separated my controller into two. 1. needs authentication 2. no authentication.
For now, i have my main controller with methods that needs a user logged in.
for example, user/story dashboard, submitting stories. etc.
The other one is my pages controller, i put there the methods that don't need any user authentication. Like viewing homepage, viewing story profile, reading a chapter, viewing user profile. etc.
In my models, i have separated them into two. account_model and story_model. Any method related to account like registration,logging in etc. and story like publishing story,fetching story data, etc.
My problem with that is that there are some methods that fall into a gray area. or some methods that i would like to group but get separated.
For example: I have a review system(my previous question), users can review other users(author) who have published their stories, stories and chapters.
In my models, the review_author method would go into account model, the review_story and review_chapter would go into story model.
Is it correct for me to just make a review_model and put them all there?
In line of that thought, can i also make separate models for separate groups of methods for example, Pagination model for any method related to pagination(user/story). dashboard model for any method related to my user/story dashboard.
The essence of my question is that i want to be as efficient as possible(of my level of knowledge) so that whenever i get far into my project i don't lose enthusiasm if i have to make changes because of the headache inducing wall of codes.
I'm not sure which title would be more descriptive, so I kept it this way. I feel kinda lost in the world of MVC.
FYI: I use PHP, but that doesn't seem of much importance in this particular case.
My problem is as follows:
I have a UserController containing the following methods:
login
new
show
overview
Then I have my UserModel, containing - in this case - roughly the same methods:
login
create
fetch
The problem is: what do I keep my user data in once fetched from the database (or XML feed, or webservice, or whatever...)? I thought of a User 'business object', containing all (relevant) properties from the database. Then, when fetching the users from the database, I instantiate a new User object for each user I fetch. If only 1 user returned from the search, I return only the User object. If more users get returned, I instantiate a UserCollection object containing all User objects - in which case I can iterate over them, etcetera.
Is that a correct way of dealing with users in MVC?
And then: imagine I made an overview of 10 users. 5 of them get edited at once - imagine a status modification using checkboxes. How do I process the changes? Do I loop over all changed User objects and store them back in the database? Then it would start to look like an implementation of the Active Record Pattern, something I'm told not to use.
I hope someone can clarify which classes and/or methods I'd need to solve this 'architectural' problem.
Since it is a rather lengthy discussion. I will give the link to an article that I have written on MVC, trying to explain it in simple terms. You may want to take a look at it.
What is MVC pattern about?
If I understand correctly, your UserModel is a bit off;
the Model part of MVC is intended as a programmatic representation of the real world model.
Meaning- it represents all the properties and actions of the real-world subject. The classic example is the Car class, which has properties such as Wheel, CurrentSpeed, and actions such as GoForward(), GoReverse() etc..
So, in your case, I think your model should be what you described as a 'user business object'.
Your controller would be responsible for fetching the UserModels from storage (or wherever), and updating them back.
your workflow would be something like this:
View would call the Controller's GetUsers.
Controller goes to storage, and fetches a list of UserModels.
Controller returns them to the view.
View displays them in some way.
And the other way around for updating.
The UserModel class would be responsible for logic that pertains to individual users (for example- ChangePassword()).
I asked here a while ago for some help in understanding MVC, since I'm very new to the topic. I thought I had a decent understanding of it, and this is documented in a blog post I wrote recently on the subject. My understanding basically boils down to this:
Controller: Determines what needs to be done to fulfill a request, and utilizes whatever models it needs to collect/modify as needed. It's basically a manager for a given process.
Views: Presentation only. Once a controller collects what it needs, it creates a specific type of view, hands it the information, and says "show this to the user however you do it."
Models: Behavior of the application. When the controller asks it to extract or modify something, it knows how to do it. It also knows to trigger other models to do related tasks (in my understanding, when a model tries to "vote for something" on StackOverflow, that model knows to ask if a badge should also be granted because of it. The controller doesn't need to care about that).
My question, assuming all of that is more or less accurate, is where do entity objects come in? Are models and entities the same thing, with each object knowing how to persist its own data, or are entities a separate concept that exist on their own and are used throughout the application?
My money is on the latter, since this would allow models to act independently, while all three layers (model, view and controller) could utilize the entities to pass data around as needed. Also, objects and database persistence seem like concerns that should be separated.
To be honest, the more I read about MVC the more confused I get. I'm about ready to just take the core concept (separate presentation from logic) and run with it in whatever way feels right, and not worry too much about the "MVC" label.
Yes!
My money is on the latter, since this would allow models to act independently
You don't want to bind your view to an Entity, because if the view also needs some other piece of data, you would have to it to your Entity. The model is entirely supportive of the view, and is concerned with supporting that view and nothing else.
For example, you show a list of your entities, what other data might you need? Current page number? Total number of pages? A custom message to be displayed?
This is why you should bind to a model, which you can freely add data items to as you need to.
Update
Here is an explanation of MVC in action...
The controller gets all of the data required for the request and puts it into the model. It then passes the model to the view.
The view then deals with the layout of the data in the model.
Each Model can be one entity that contains some methods to control and use its data.
Is it enough?
I have a question about the best practices of placing certain functions in controllers in an MVC web framework.
Lets say I have a User & Tags controller. I have a function/method called addTag_to_user().
What is the conventions or best practices for placing this in either the Users or Tags controller?
Though personally I am more inclined to place it in the tags controller as my Users controller may be full of other functions as it is a key element (for example). Thus placing it in the Tags controller improves the readability of the User controller.
Edit: Maybe it doesn't really matter where you place functions that deals with two models. I want to see what other people's conventions are.
The Controller object can hold behaviour which manipulates the Model domain. However, MVC normally has one controller for each domain, and it sounds like "User" and "Tag" belong in the same domain.
With the Information Expert Principle, Who has the information to fulfil this responsibility? A Tag has no idea about a User. The logical answer is that the User is responsible for his/her tag's. So your User Class would hold addTag() behaviour.