CODEWITHSUNDEEP
asp.net-mvc
Danny
Danny

Reputation: 2821

Creating ASP.NET MVC application with different product categories

A website like www.halifax.co.uk offers different product categories, like mortgages, savings.. Mortgage and savings products will hold different data fields. This does not fit with having a single products controller that would be used in the majority of cases. A single products controller or a controller for each product category?

Upvotes: 1

Views: 798

Answers (2)

Praveen Angyan
Praveen Angyan

Reputation: 7265

The simple answer is that it depends on the amount of "business logic" that each product category carries with it. You have to look at your domain model and see what your product categories really means in your domain.

In a case of an auction site for instance, the focus is on the product. The category is really just a hierarchy of strings that can be used to tag a product. Since the available categories also grow and shrink on a day to day basis, creating a controller for each category would create a maintenance nightmare.

In the case of a banking site, the focus is on each individual product category like "Savings Account", "Credit Cards" etc. There is so much difference between these different categories that it makes more sense to create individual controllers for them.

Upvotes: 1

FOR
FOR

Reputation: 4368

On one side each of these product categories might have different number and type of fields. A simple approach is then to have different controllers, each leading to different views, strongly typed to different models. "Mortgage" would be one model, with its own fields, and its own Index, Details, Edit, and Delete Views, and a MortgageController. Similarly for Savings. This is the simplest approach to ASP.NET MVC applications, using strongly-typed views. Note that even in this scenario duplication can be removed or minimized by careful care and refactoring of the controllers (and models, and views of course).

However, I'd recommend analyzing the behaviour of each of these product types. If, in fact, they all behave the same, there are ways to get around the issue of different number or type of fields. For instance, all the different type of models could inherit a common base class, or implement a common interface (the latter might be the better of the two solutions - but it's difficult to say if you should prefer inheritance or composition in this case). These are but two options available to develop "weakly-typed" views and controllers.

I can't say whether you should go one way or the other from the brief description you gave, but I'm convinced the answer is in the behaviour of the models (rather than their structure). In my personal experience, models that behave the same (e.g.: they all expose the same CRUD operations) should be handled in a single manner, but behavioural differences (e.g.: different business rules to be verified when a model of a specific type is being saved) need to be handled on a one-by-one case. HTH

Upvotes: 1

Related Questions