i am currently developing a login and registration system,
The login system(its own controller, model and view) includes function such as:
validate, if_uname_exists, if_email_exists, etc
registration system(its own controller, model and view) includes functions:
register,send_activation,send_email, etc
However i have a need to make a user controller, which has the username as a data member, and i need to call on functions such as is_admin(), update_profile(). So my doubt is, should those functions be included a user model, or rather can i have them in another model, for example: login model or maybe a profile model?
Are there any best practices to follow on the same?
Thanks alot
yes absolutely. one controller many models.
another thing to consider - and note not everyone will approve of this but lets say you have a User model and then you need other models that are related to User but different. you can create a user.php model and then create a folder also named user. your model directory structure will then show your app structure like
user.php
user/create.php
user/emailnews.php
user/relatedcontent.php
this allows you to have shorter model names - and it still all makes sense. typically you would then have abstract methods in the user model and call specifics from the models in the folder. even if emailnews only has one method - breaking it out like that helps to document your application.
Related
I'm new to MVC pattern and Sails. From my understanding, it seems like I should create a controller for each model. A controller is like one page.
So, if I want create a page containing product category, product list and user authentication, there are 3 models in my page. How should I structure the controllers?
You don't have create separate controllers for each model.
Controllers handle the request from the client and return views, JSON, etc.
You may be being influenced by how sails documentation explains things due to their blueprints.
Mvc does not require a 1 to 1 of controller to model. Your controller should take care of massing the data and rules needed to show your view or a group of different views. A controller may have a link to a group of your functionality e.g. user management where you handle registrations, login, forgotten credentials etc. This may require a few different models and not just your user model. It may also display a number of different views too.
Sails.js comes with blueprints enabled which means a user model will have create,update,find,findone etc against a user model. Infact sails doesnt need a controller in this instance but you could make one to over ride logic or add additional logic. There is however nothing stopping you calling a user.find method in the user controller as well as a pets.find. Just think of the controller as the conductor telling and calling everything to fire and bringing this information together to push into a view or number of views.
I have a model that I require to update, such as User. In a large application, this User will also have relationships, and updating it would be more than a mere User::find($id)->update(Input::all()).
Should the updating be performed in the Controller, or be a method within the User model itself?
I always thought that I should put it in the model, since it is model specific. But I've seen most people perform the task in the controller. What is the reasoning for this?
As said in the pattern names, the controllers control any model query or update. Based on this, the controller will be responsible for fetching, changing and saving the model.
If some actions are to be reused in many controllers, acting on a set of models, they would go in a "repository".
In your example, you are using Input::all() to hydrate your model, which you definitely have to change. Any user value has to be checked and/or sanitized. I would also recommend against using all and prefer either get or post, so you set up a minimal restriction.
So, I definitely let the controller be responsible for the "glue", having repositories for any collection matter, services and hydrators to change the object, and the model itself staying for only getters and setters, managing their own data in their own scope.
I have actually 3 questions, but similar to each other:
I have a model called Permissions. and I need another model ie. Users. what is the proper way to user Permissions inside Users.
You get what I mean above, is that weird or is there another better way to do it.
This Permissions model, will be used globally throughout my application, what is the way to use it in other models or controllers (similar with 1st question)
One way is to get the global variable for the main CodeIgniter object, and then load the model from that object rather than $this:
class Permissions extends Model
{
function MyPermissionsFunction()
{
$ci =& get_instance();
$ci->load->model('users');
$ci->users->MyUserFunction();
}
}
You can also sidestep the issue by combining your models together into one larger model. The main reason to keep them separate is to only load the models that you need; if you nearly always use both together (as would make sense, for Users and Permissions), you may be better off taking this approach.
I'm getting some trouble understanding the MVC concepts.
I'm building a User model, you know? Application_Model_Users. They say that the models should only contain the structure... and the business logic should be put in the controller.
So, consider a function called authenticate($user, $password). This function will return true if the username and password entered is valid or false otherwise. Where should I put this function? In the controller Authentication or in the model Users?
Thank you!
Related to the Model, whenever you need to retrieve data(from DB, Web service, filesystem) or save data, you need a model to do the job. In MVC, a model is not understood as a mapped table, maybe more like a mapper. Zend has some info about this at their site, it could help you understanding mvc a bit more.
When it comes to user authentication, you should certainly implement the authenticate function inside the Users model, I would think you will do a database check against a table or similar.
Just in case you are not already using it, Zend comes with a package for auhtentication: Zend_Auth (http://framework.zend.com/manual/en/zend.auth.html) , it could speed up implementing the security at your application.
Although Model operations often include storage operations (DB, servicer, etc), it is not limited to that. Model, as far as I know, should countain Business logic entities, this is, classes that represent your business entities, like User, Person, Customer, etc. Each class should define its own operation methods, in example, a Person model class should allow you to get a person's name, calculate his/her age according to his/her birth date, etc.
Also, there should be specialized classes for Model storage and retrieval. With these classes you could fetch all your Customers, or only one, using certain conditions, etc, or save a modified Customer class instance (in example, a customer changed his/her address or phone number).
This separates the storage/retrieval operations from Business login operations.
So, according to your question, your model could have a class that allows you to find one user by its user name and password. If the user is found, you could return a Model_User class instance (in example). Then, using the standard Zend_Auth class, or extending it to create your own authentication class, you can use some Login form parameters to perform the user authentication.
Follow the Zend Framework quick start guide, there are the basics about MVC in Zend Framework. Also, there you will find some resources about Zend_Db and related classes, to allow DB interaction. There are also Zend_Db_Table, Zend_Db_Table_Rowset and Zend_Db_Table_Row classes, that you could extend to fit your model storage needs.
I have a personal solution where I extend Zend_Db_Table for my (in example) Model_UserTable class, used to store or query my Model_User entities. And my Model_User class extends Zend_Db_Table_Row.
I'm slightly confused about the controller-model relationship in MVC.
Should a controller be able to access any model in the system or should it have a 1:1 relationship with a specific model? Both options seem to present problems:
If the relationship is 1:1 obviously if something elsewhere needs to be updated it can't for example updating a window title from outside the window triad. So should models have access to other models (And how do they find them?)
If it's not 1:1 and the controller can access any model, how are these usually accessed (service locator?) and what if there needs to be more than one instance of a specific model.
I'm a bit confused! Thanks for any help.
For basic CRUD abilities I think a 1:1 relationship works, but it is by no means a rule that every controller should have a corresponding model. That being said, I obviously don't think it's an issue to access multiple models within a controllers.
The only thing that has a 1:1 relationship in my MVC applications is models and tables.
The MVC paradigm is based on one main rule, namely separation of concerns. Making a controller 1:1 dependent via some kind of relationship with a model is not separating those concerns, but making them more unified. A controller called "users" should only talk to a model called users, but why go and make that a explicit relationship?
Models should almost always exist in an exclusive static context, so they are easily accessed within controllers and other models.
Usually I don't access the model direct from the controller. I usually add another layer between the model and the controllers.
For example:
Controller Layer->Service Layer->Model Layer
For every Model class, I build a Service class to access it and the Controllers can access every Services in the application.
I think it's a good way to do things.
If you need some examples, please ask. :)