2

Fellow developers on other teams I interface with seemingly question my judgement calls as they pertain to the placement of coded business logic in a .Net MVC/Knockout web application currently under development. Granted, these types of questions have far reaching implications as they pertain to high-level architectural design patterns but warrant a detailed analysis nonetheless.

For example, let’s say we have a chunk of code that pulls data from a database, runs some calculation and then validates it against some user input. The argument consistently raised is such that the layers outside of the client browser (depicted below) should simply facilitate activities such as storing and passing data, security and other such activities that fall outside of implementing business logic. Then, within the browser, business rule validation and implementation.

[Client Browser/JS] <=> REST <=> [IIS/.Net MVC] <=> WCF/SQL <=> [WCF Endpoints & Databases]

Granted, there are numerous client-side JavaScript frameworks do promote this type of implementation pattern but I believe the intent with these assumes that the business rules and processes will always be executed client-side. Said another way; coupled to the browser.

In my particular circumstance I’ve come up with a few arguments against such an architecture and I want to make sure I’m not missing anything or being misleading.

  1. Testing: While we can leverage testing frameworks such as Jasmine the level of effort involved with developing and integrating these types of test scripts is substantial compared to the TDD approach used with other back-end .Net development methodologies.

  2. Debugging and Development: Similar to my testing argument; most mainstream browsers have great development and debugging plugins that make development far less frustrating and enjoyable today. However, these still do lack the richness in capability and ease of use when debugging domain/business objects on the back-end within Visual Studio.

  3. Coupling: Domain/Business logic is tightly coupled to JavaScript runtimes. The browser in this case.

  4. Code Security: This is one is pretty straightforward.

  5. Cross-Browser Compatibility: While less of a problem today it does warrant some consideration.

Is there other high level items or constraints that I may be missing?

  • I generally only use front end client javascript for presentation. Even if I am using Angular JS, I'm not using it to do business logic, I just use it to transform some JSON spit back from a rest api into some HTML. Even if my entire client is javascript, I still have backend rest or controllers surfacing all the data. That backend code still runs through security checks, validation, etc. In fact these days I do all of my forms with angular js and bootstrap because it's a breeze, but I still validate there input in the controller being posted to. – Ryan Mann Jun 18 '15 at 6:05
1

I write this from the perspective of a long-time .NET developer being pulled inexorably into the client-side JavaScript world, so I assume that I probably share some of the same biases as you. I only bring this up because I think a lot of your bullet points are probably biased by your experience and relative comfort with C# and .NET over JavaScript.

For instance:

  1. Testing: While we can leverage testing frameworks such as Jasmine the level of effort involved with developing and integrating these types of test scripts is substantial compared to the TDD approach used with other back-end .Net development methodologies.

That is being challenged daily by the JavaScript community. There is a significant amount of effort that goes into a proper .NET TDD approach that I think you're glossing over here. Certainly no more so than the ever improving JavaScript testing frameworks. But, as you are presumably more familiar with the .NET-related tooling and practices, it seems what you're really concerned with is the learning curve associated with adopting JavaScript-related new tooling and practices. That's a valid concern, but not really the same as ".NET is better".

  1. Debugging and Development: Similar to my testing argument; most mainstream browsers have great development and debugging plugins that make development far less frustrating and enjoyable today. However, these still do lack the richness in capability and ease of use when debugging domain/business objects on the back-end within Visual Studio.

It's hard to argue against the rich debugging capabilities of Visual Studio, so I won't. :-)

But, I would argue that the vast majority of the time (in my experience) only a small subset of the debugging capabilities of VS are ever being used. Most of what happens in the debugger is stepping through the code from breakpoint to breakpoint, inspecting flow and state along the way. One could argue that this can be done just as well in (well designed) JavaScript code on the client as it can in C# code on the server. Especially when using VS as the debugger.

  1. Coupling: Domain/Business logic is tightly coupled to JavaScript runtimes. The browser in this case.

I'm not sure I agree with this. Well modularized JavaScript code does not need to coupled to the browser. Business-logic code (as opposed to DOM-manipulating code) can and should be written such that it can be executed and tested without the browser.

  1. Cross-Browser Compatibility: While less of a problem today it does warrant some consideration.

I agree. When writing code for .NET on the server, you know and control what runtime environment your code is running under. With JavaScript, there may be subtle differences with some code between the different JS engines. I wonder how much of a real impact this would make, though. Have you come across an actual example of this or is it hypothetical at this point?

  1. Code Security: This is one is pretty straightforward.

This is the big one, for me. And the deal-breaker. It's simply the case that code running in the browser (and not on the server) is out of your control, unless you can control the browser, too. A responsible app would have to double-check all of the business-logic performed on the client, since the integrity of the client should not be trusted. This would seem to me to lead to either a lot of duplicate code, or an untrustworthy app. This is less of a concern with an internal-only corporate app than with a site open to the public, but it should still be a concern nonetheless.

All of this is to say that, if I were on your team, I would agree with you. :-) But not for the reasons you provided, which wouldn't be very convincing to someone eager to embrace JavaScript and client-side programming. And those arguments are getting weaker by the day.

  • Thanks for expanding on this further for me. I could've been clearer with point 3 though. My intent there was to point-out our IOC libraries/business logic layers are used in other areas such as windows services etc. If we were a Java shop then I believe this wouldn't be an issue in that context though. – Christopher Felpel Jun 18 '15 at 15:04
0

I think many of your main points are quite misguided; claiming that "yes browsers can do it but Visual Studio is better" is not going to convince your coworkers (who probably are more used to debugging JS than to working with VS). Also:

  • number 3 is not an actual issue; you can write JS that does not rely in the browser version and that means no more restriction that you would have by writting it in C# (in fact it could be argued that you are restricting yourself more by using C#/CLR, since you can run JS on your server).

  • number 5 is also senseless; even historically, most cross browser issues have been related with the implementation of the DOM (how to access a form, input field, which properties those support, etc.) than with the JS itself. A well written JS should have no issues.

The main factor is that, as always, you cannot trust the client. Unless the result of the business logic is only output for that client use, you cannot implement it because you cannot be sure if that result comes from your logic, or from other piece of software claiming to be your logic.

Imagine that your bank worked like that; when you logged in it would send your browser the status of your accounts at your last login and the list of transactions that have happened, so that the browser calculates the current amount in your accounts and sends that data back to the bank (who would store it in their DB). Does that sound right? Maybe someone would try to profit from this architecture?

Even in a schema where people would not profit, like SETI@home1, some people "hacked" the legit program just to improve their statistics. If someone would benefit from feeding your system false business results, at some point someone will try. Moving the business logic to the browser just makes it insanely easy to do so.

Additionally, moving your logic to the customer will usually mean that your data will be harder to secure, since you will need to give access to almost everything to the browser so it can process the business logic. Getting the granularity that allows access to all that is needed but not a single bit more is going to be a lot of work.

1: In case you do not remember, SETI@Home was a program that you installed in your computer to process data from a radiotelescope in its spare time; in the hope of finding a signal send by an extraterrestial life form.

  • Note that the point is not JS vs .Net but "on our servers" vs "on someone else's hardware". A .Net desktop client would be again the wrong solution, for exactly the same motives. – SJuan76 Jun 17 '15 at 17:15
  • I feel like this entire issue goes away with serverside javascript. This way you can write shared javascript code, like entity validation, input validation, etc, once and have it run in both the client and server. You then have client-specific JS (DOM interaction) and server-specific JS (database stuff). Not sure if anything like that exists, but it would be interesting. – Slight Oct 12 '16 at 18:18

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.