Suppose you are to create a single, global e-commerce application to support multiple markets in different regions of the world using ASP.NET MVC.

Although most of the business logic for the application is reusable for different markets, some markets want to implement their own views and client side validation logic depending on the controller action called. The controller logic should remain the same, only the view should be altered depending on the specific market's need—and they will supply the view to use.

In short, you need to provide a way for your MVC to be extensible for these situations.

  • What recommendations can anyone provide as to how to best handle this?

  • What are the best practices around extensibility with MVC controllers/views within this context?

  • Or is it a bad idea overall?

I'm hoping for something clean that reduces the risk of breaking the rest of the MVC code base.

  • What about a complete client / server separation? Server side provides only authentication and data, while the client side is pure HTML and Javascript -- there is no HTML generation from the server side. The presentation can be changed completely with no change to the code running server-side. – kevin cline Sep 24 '14 at 15:10

Wait, they want "to implement their own [...] client side validation logic", but not server-side validation logic? This sounds as an important issue, security-wise.

In the same way, having a bunch of views written by a third-party running on your server is out of question, since those views can contain harmful code.

Now, if you need to let your customers to extend your application, you need to have plugin architecture. One way is to use MEF. Another way is to create your own implementation with AppDomains.

You can find an example of such extensibility here. Note: the code is written by me and is covered by MIT license.

In both cases, you should be very careful with permissions you grant to the custom-written code. Since it is written by third-parties and runs on your servers, make sure you understand correctly (and test thoughtfully) what can be accessed by the code, and what can't.


Abandon server-side views completely and have the server side deliver only data (JSON, XML, whatever is convenient, but not HTML). The client side will be pure HTML and Javascript. That allows clients to present data any way they like without requiring any server side code.

However, this statement is troublesome:

their own ... client side validation

Client-side validation is for the convenience of the user. Validation still has to be done on the server side. One approach is to allow them to specify validations in a small language that can be interpreted at runtime. For example, validation could be limited to regular expressions on each value from the client side. Another possibility is to run code in a sandbox so the code can only operate on the data provided.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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