DRY principals vs. light/thin views in MVC for similar/inherited objects

Question

I have a series of inherited objects that are all very similar with just a few fields varying between classes. At the base of this class hierarchy is an abstract class that contains many several fields that all subsequent objects should have. Something like this:

abstractBase
  obj1 : abstractBase
    obj2 : obj1
      obj3 : obj2

The view that displays these objects is essentially the same for all of them, i just introduce new divs to display the data that is different. As I am fairly new to MVC this leaves me with just two primary options:

One approach would be to create strongly typed views for each concrete object. Each view would be very similar but with slight differences for the underlying objects. In my mind this violates the DRY principal as 90% or more of the content of each view would be repeated in the next one. But on the upside the views would be void of any significant logic.

The other approach would be to bind the view to the base abstract class and then introduce checks against the inherited classes to determine if i need to render out something. something like:

if (Model.baseObject is obj3){ render out the special fields }

On the upside, i will no violate the DRY principal, which i view as a good thing. But on the downside the views will then contain logic. As i understand it, this is more or less frowned upon.

• Anyone out there been in a similar situation?
• What approach did you take?
• Is there another option I did not see/was not aware of?

Right now I am leaning *towards heavier views and less redundant code. it SEEMS better.

Thanks

Answer 1

I agree with the chosen answer to How much logic is allowed in ASP.NET MVC views?

Essentially views are meant to serve as a structure for the display of your model data. Therefore, the view is serving its purpose if the structure it creates for the display of a specific model can be adjusted based on the data contained in the model. Conditionally displaying elements in your view based on certain properties of the model it is meant to render is an acceptable practice.

If your view contained logic to modify the model data in any way, this would violate the separation of concerns that MVC is meant to establish.

Answer 2

I think you should follow the first approach having strongly typed views. You can have ViewModels which are specific those views and then bind to the view. Wherever you feel Reusability of a ViewModel present in another View, Make use of PartialViews.