I am planning to design a new web application using ASP.NET MVC 5. I used to write a lot of JS/Jquery code on UI when I was a beginner with Web forms applications. After reading/learning a lot of software designs/patters/practices:

  1. MVC pattern suggest that you should not include any business/application logic on Views or even on controllers. This is enforced because of SoC principle (Separation of concerns). In such cases,writing a logic of manipulating few fields is violation of principles ? If yes, up to which extent we can use JS/Jquery? or what are the best use cases?

  2. on other way, Microsoft suggest the best design approach is to choosing between client vs server side processing (as per 70-486 exams). if I process a logic at client side I will be violating the SOC and other principles,if not I will be making application more bulkier to load. well, I too understand that logic should retain in model classes(or domain classes) but to achieve the same I have to make a costly server side trip.

Well, I know MVC uses JS for validations and few other functionalities. If I have to achieve the client side rendering/processing javascript frameworks such as Angular/Express are famous now a days. I have read quite a few articles about Hybrid implementation but never got the idea of its actual benefits. Because to do so, I have to manage two separate MVC framework-one on client and other on server side. how can I test a whole functionality in such cases? Will writing a hybrid application still satisfies the SoC/IoC principles and standards?

Note: I am talking about enterprise, large scale web applications.

1 Answer 1


You're considering your application as an architect. For a software architect, it would indeed make much more sense to put all business logic on server side. For a developer, it would be great as well: there are a lot of difficulties developers have to overcome when having part of the logic on server side, part of the logic on client side, and part of the logic on both sides at the same time.

Instead, you may consider your application from the perspective of a user. For a user, SoC doesn't mean anything. SOLID principles? Layers? Don't care. What the user cares about is performance and user experience. Imagine a registration form. The user has to enter a user name and type twice a password. One application would run AJAX queries to check if the user name is already in use, or do a match between two password fields to inform the user in real time that the values don't match. Another application would wait until the user submits the form to inform him that something went wrong. Which one is faster and more comfortable to use?

As a software architect, when you have to write a web application which has logic on server side and on client side, you may:

  • Consider that you have two applications. The client-side one simply interacts with the server-side one. This would ensure that the design principles are limited to one application considered in isolation.

    More globally, consider your client-side application as just a consumer. There may be others, which are on the same level. For instance, you may have a JavaScript application which runs in browsers, an Android and an iOS application to run on mobile devices, and a desktop app for PCs. All those apps should be using the same server side application.

  • By using REST, you can decouple even more your server side application from its client counterparts (JavaScript one, Android app, desktop app, etc.) The server application becomes what is called a service.

  • Generate client-side code from server-side code where the business rules are the same. In ASP.NET MVC, this is what happens with field validation. You don't write any JavaScript code for that: you simply add validation attributes to your model, and the framework takes care of generating the corresponding JavaScript for you to have client-side validation which matches exactly the server-side validation.

  • Make it explicit which business rules belong to client side, and which ones should remain on the server. The goal, here, is to avoid for your team to search for the rule in the wrong place, or, worse, reinvent the wheel by rewriting the rule which was already implemented on the other side.

Following the comments about security aspects:

I don't want to expose data layer or service layer on client side.

That's good, because you shouldn't.

Exposing a data layer is practically like giving your SQL credentials to the users and letting them access and manage the data.

This is why, in my answer, I was saying that you should consider that you have two applications: client-side app and server-side app. You don't expose your data layer to the Internet; what you expose is the interface of the server-side application which was specifically designed to be accessed through the Internet.

For an example, I don;t want whole JSON to be returned on HTML page and on HTML page I should be writing a logic to display/hide/calculate something.

If a given client is not expected to see the specific information, the information should not be included in the JSON response. For instance, there is no way for me to get your YouTube watch history through Google's API. I know the endpoint which returns the watch history, and I may even ask you to give me your account identifier to be passed to the API. But unless you explicitly authorized me to read your history, I will never be able to see it, no matter how hard I try.

The purpose of the display/hide logic which runs on client side is to enhance the user experience by showing only what is relevant to the user at a given moment.

For instance, on the page you're looking on right now, there is a question, and there is an answer; there is no dialog which allows me to share your question or my answer, and there is no window which allows me to cast a close vote or to flag your question. There is no form to add a comment either. All those missing parts are hidden behind small “share,” “edit,” “close,” “flag” and “add a comment” pieces of text which, in turn, populate the corresponding windows. This behavior is very convenient: when I read a question, I don't necessarily want to close it, nor do I immediately want to share it. Occasionally, I want to do so, in which case a simple click shows me the relevant controls.

If JavaScript interaction is removed, either all those forms would be shown permanently, and would clutter the page, or they will still be hidden away, appearing as hypertext links. In this second case, I would have to wait until another page is shown just to get a simple share link, which is not exactly how I imagine spending my time on this site.

Independently of the presence of JavaScript, the web app (REST service; whatever) should only return information intended for the user. This is true for a website with no client-side interactivity, as this is true for an app which heavily relies on AJAX.

because it would be easily hack-able and someone can take benefit of it.

As previously stated, independently on the presence of JavaScript, the web app should always return only information the user is allowed to see.

A REST service is by no means easier to hack than an app which returns HTML, because there is nothing special about REST. In both cases, the server processes a request and returns some text in response. The fact that the text looks like JSON and not HTML has no effect on the security.

Source code that sits on the client-side is easily readable and capable of being reverse-engineered if it has been obfuscated.

In terms of security, this is irrelevant: if you rely on security through obscurity, you're pretty much screwed anyway.

  • Thanks for your descriptive answer. it helped a lot to understand. I agree SOC or any principles doesn't mean anything to customer except rich user experience. But, I have to consider security(for your login example), modularity and what not. I am fully supportive of client side processing but how better we can handle security(consider my self new to security)?I know that with ASP.NET we can write JSON actions to provide a better UX. but is it good to violate the principles(I know the answer is YES) but I would like to hear more from your experience. Cheers! Sep 24, 2018 at 4:23
  • @DirtyDeveloper: what exactly bothers you in terms of security? Sep 24, 2018 at 9:00
  • I don't want to expose data layer or service layer on client side. For an example, I don;t want whole JSON to be returned on HTML page and on HTML page I should be writing a logic to display/hide/calculate something. because it would be easily hack-able and someone can take benefit of it.Source code that sits on the client-side is easily readable and capable of being reverse-engineered if it has been obfuscated. Sep 24, 2018 at 10:30
  • @DirtyDeveloper: I edited my answer to address your concerns. Sep 24, 2018 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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