TQ
dev.com
Blog about software development
31 Dec 2022 - by 'Maurits van der Schee'
Software development benefits from separating the presentation, business logic and data access. The concepts of "tiers" and "layers" in web development aid this separation. Within the application tier three layers can be identified. This blog proposes two rules to get a well-structured, more secure and more scalable application: (1) The data access layer and the presentation layer should be executed sequentially. (2) "Safe" requests should only read from the data access layer. This approach should be enforced by MVC web frameworks to guide developers towards better applications.
A "tier" refers to "a functional division of the software that runs on infrastructure separate from the other divisions". So, in a web application you have 3 tiers:
Within a single "tier" people talk about "layers", these are dealing with communication with the other tiers. The web application that you are building may have 3 corresponding layers:
Martin Fowler agrees that one should use "layering to separate domain logic from such things as persistence and presentation responsibilities".
Since the application layer handles the HTTP request, it will in it's turn call the data access layer and the presentation layer. It should do so in that order and in two separate stages. The data access layer should be called in read-only mode in cases where no state change is expected. After the application layer has received the data from the data access layer, it can send the data to the presentation layer for displaying. More specific:
I believe these 2 rules make web development applications well-structured, more secure and scale better.
Within modern MVC web frameworks the presentation layer is often represented by "views", the application layer lives in the "controllers" (with or without a set of "services" containing business logic), while the data access layer is often some form of Object Relational Mapper (ORM) that produces objects from "models" that map onto database tables (sometimes queries are grouped in "repositories").
Martin Fowler says that this is not "true" OOP, but actually a "procedural style design". I think he is not wrong, but then again I'm not a self-acclaimed "object bigot", so I don't see the harm in a (somewhat) procedural style.
Applying the above rules to the MVC terminology we get dumb data objects retrieved from the ORM that are explicitly passed (or "pushed") to the views, while views cannot retrieve (or "pull") new data objects. Also the controller's actions should automatically be marked as read-only when they cannot write to the database. The read-only concept should also apply to the session data. The current MVC web development frameworks do not enforce the two rules stated above, which I feel is a missed opportunity for best practice guidance. Please let me know if you find a web development framework that does.
Data retrieval before presentation leads to shorter (and thus less concurrent) connections to the data access tier. Read-only request may reduce writing to the data access tier and these requests may not hit the data access tier at all. They can often be served from various caches, depending on the consistency guarantees that are requested (using request headers). Since the number of concurrent write requests to the data access tier is the hardest thing to scale in a (typical) web application these 2 rules are important. These 2 rules allow you to scale to high user counts with only a single primary database server.
Enjoy programming!
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe