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]
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.
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.
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.
Code Security: This is one is pretty straightforward.
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?