ADSD course - Traditional layered architecture
This is the first in a series of four blog post following up on a training course I attended earlier this year.
The views expressed here are solely mine. The inspiration came from course but the viewpoints presented here are not necessarily the viewpoints of Udi Dahan.
For years we have been using a layered architecture like the one depicted here:
Detailed information about this architecture can be found here, here, and here.
Do we really need three layers, a database, and multiple data transformations? This particular architectural style has been around for years. I do not want to go into details about why this architecture is useful but separation of concerns is the keyword here. When OO languages got popular we definitely needed the mapping layer between the OO language and the relation database - hence the ORM transformation.
This architecture can be deployed in a multi-tier environment for either a traditional client-server solution or a browser-webservice solution.
JavaScript was originally creating a part of the first web browser, Netscape, but over the last 5 years the language has really emerged into a full stack all purpose programming language essentially being the lingua franca of the web. Quite a number of databases supports JSON. Even SQL Server 2016 will have a native JSON interface. JavaScript is everywhere! Why not just skip all the transformations and layers and use something simpler like:
Separation of concerns is still important and this simplicity of the picture does not imply that the code running in the browser is one big chunk of spaghetti code. Popular JavaScript framework like AngularJS and Backbone.js provides the means for structuring your app in a MVC.
An easy way to get started with this architecture would be Azure DocumentDB.
I am not saying that this approach is applicable for all cases but the point is that technologies change and maybe we need to change our way of using these technologies - not just replacing one technology with another without reconsidering processes, patterns, and best practices as well.
Please create issues at the Github repo Twitter.
Edit page on GitHub. Please help me to improve the blog by fixing mistakes on GitHub. This link will take you directly to this page in our GitHub repository.
There are more posts on the front page.
Content of this blog by Carsten Jørgensen is licensed under a Creative Commons Attribution 4.0 International License.