Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you are building a web application, and you have a user management component, is it recommended to do:

class UserAdminView extends View {



class UserAdminUpdateView extends View {


What about controllers? Thoughts?

share|improve this question
have a look -… – Yusubov Jul 29 '12 at 4:34
up vote 2 down vote accepted

It will depend on which web-development design pattern your team is set to go/follow.

For example: in MVC design patter, each view it is recommended to have a dedicated view-model. While your models are the constructs that serve as a data containers, it is not recommend expose them directly as view-models. Thus, depending on view requirement, a custom view-model is build from a single or multiple models.

Important productivity tip: for a convention-based object-object mapper always try to look fr tools like AutoMapper. It will save tons of time during the development.

share|improve this answer

If you want to do it MVC style, I personally most of the time have different views for different actions. In some cases, when the content for show / edit / save / list or whatever I had there was very similar I used only one view. But rarely.

As for the Controller, there should be one controller with different methods for the different actions.

As for Model. I consider models kind of redundant. I use them only to validate forms and only because they integrate with the framework.

Business logic should be outside the MVC framework, which I consider only a delivery mechanism to the application.

PS: I know many web developers will not agree with my last statement. Don't flame, think. Thanks.

share|improve this answer
I consider models kind of redundant -- Really? They are the M in MVC. – Robert Harvey Jul 17 '12 at 21:04
@RobertHarvey: yes, models are the M in MVC, but not necessarily the business model with all the business logic which should indeed be somewhere in a middle tier between the front-end MVC and the back-end database. As such the M in a front-end MVC can be very anemic... – Marjan Venema Jul 18 '12 at 6:00
In PHP it's a bit too easy to drop the models, and just use some kind of associative array. – Matsemann Jul 18 '12 at 6:55
I look at the models in the sens of "Request Model". A structured, filtered and validated form of information which passed to the business logic. I know this sounds strange for those used with putting all the business rules in the Models inside the MVC, but if you want to separate your delivery mechanism (aks. UI, the MVC framework) from the core of your application, than the above explained situation is in effect as Marjan explained. – Patkos Csaba Jul 18 '12 at 21:18

I think that the first approach "class UserAdminView extends View" is better. UpdateView fits better as an method of class a than an actual class.

If you want UserAdminUpdateView to be inheriting from a class than the superclass should be an UserAdmin class not a view class.

share|improve this answer

Taking a look at a popular MVC framework such as Codeigniter for PHP or even the structure of Play Framework (java) should help.

For example in both cases the idea of a view is that it seperates the coding from the templating (gui). Creating an individual view as its own class confuses this as a front end developer shouldn't be using code. It would be more beneficial to create a view class which effectively allows you to load HTML based templates and pass your data to them. For example:

class userAdmin extends Controller {

  public void view() {
    data = userAdminModel->getView();

  public void updateView() {
    success = userAdminModel->updateView(...);

The controller invokes the method based on the users action. This method performs any business logic requesting any persistent data from the database using the model. The data is then passed into the view which is effectively a templating engine which has rudimentary scripting to iterate through such data.

The brilliance of the MVC model is that a developer can create the logic that passes the expected data to the view. A HTML/CSS developer (for example) with limited coding skills can then create the front end which uses variables passed in without any concern over how the data is generated and has been manipulated.

The model allows you to access the data within the controller in a standardised way without worrying how that data is stored.

I would suggest googling MVC for a more indepth look.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.