phenam Posted November 9, 2010 Share Posted November 9, 2010 With the idea of "code to an interface, not an implementation", does this mean that we shouldn't be instantiating models directly within controllers? For example, if I was accepting user registration information, is it ok for me to instantiate a user model to put the input data into, or is it better to go through some factory class/other method to create my model? Quote Link to comment Share on other sites More sharing options...
KevinM1 Posted November 9, 2010 Share Posted November 9, 2010 With the idea of "code to an interface, not an implementation", does this mean that we shouldn't be instantiating models directly within controllers? For example, if I was accepting user registration information, is it ok for me to instantiate a user model to put the input data into, or is it better to go through some factory class/other method to create my model? Generally, most people try to keep their controllers thin. The controller is the crossing guard - it should pass data along to where it should go (the model, the view), but it shouldn't be responsible for actually manipulating it beyond that. Even with ORMs, many people create Repository objects to act as a facade in order to keep the model details hidden from the controller. Quote Link to comment Share on other sites More sharing options...
phenam Posted November 10, 2010 Author Share Posted November 10, 2010 Hey Nightslyr, thx for the input, I really appreciate it. Can you explain what the difference is between data mappers and a repository? Does the repository act as a layer between the controller and data mapper? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.