Data oriented programming is here to stay and along with it comes the deconstruction of popular programming idioms. When coming from a productivity oriented stack the typical 3-layer idiom is DAL, BLL, and OBJ. These would be "Data Access Layer" and "Business Logic Layer" and "Object Layer". "Object Layer" is interchangeable with "Presentation Layer" depending on the architecture of the application. Whether it's native apps or web apps there is probably at least one application with this architecture buried somewhere in the repo at nearly every company I've ever worked at.
What Happened to N-Tier?
After years of maintaining applications like this I can say wholeheartedly that each one becomes much like the subject of Chemistry where typically there is no good place to start. Using N-Tier monstrous applications begin to unfold and over years of maintenance a lot of code gets developed just interacting with the "Layers".
Rather than some silver bullet solution getting developed the term just became more popular to describe interfaces to data. That is an idea I can actually get onboard with because that is exactly how it feels. The term "Interface" in Object Oriented Programming changes every year because (surprise!) it just takes whatever it takes to communicate with "Layers". The new definition in C# 8.0 for interface is IMHO everything but the kitchen sink except for state to be used in tandem with classes.
Okay...well what about C++ I mean an interface in C++ has to be very specific right? Actually, there aren't any concepts in C++ which use the term "Interface" but a similar concept is the use of an "Abstract Class" which cannot be instantiated but can be used as a base class. A class is made abstract by declaring one of it's functions as a pure virtual class. The newer updates in C++20 allow for "constexpr virtual" (you can read about it here constexpr-virtual). In a convoluted sense- the "Interface" got another update.
This is getting complicated
What I think we should really be after is creating interfaces where layers of data are not so coupled. Depending on the interface it may need to be tightly coupled or it may actually be running in a container or VM somewhere or on another port. The interface should be standardized within an organization if needed. This might be why it's common to see the term "Interface" and "Layer" being used almost interchangeably in recent times. I would recommend creating an "Interface" that can talk to multiple "Layers" or creating a "Layer" that can have multiple "Interfaces" but going 1-for-1 is where the code bloat comes from. It's actually very easy to create an "Interface" for each "Layer" or vice versa. It's very challenging to create reusable code on either side but happens to be the cleanest solution.
NoSQL Layers and APIs
Now that we've delved a little into "Interfaces" and "Layers" the programming model becomes even more reduced in the world of NoSQL. Respectively, when it comes to Cosmos DB or FoundationDB, the "Layer" is something which resembles more of an API which translates the resulting output to NoSQL using an "Interface". This is a shift away from N-Tier because no longer can N-Tier fit all of this into its definition. Solutions are still being developed under FoundationDB and the solutions for Cosmos DB are varied but hosted only on Azure.
Both systems are in heavy use worldwide and the concepts of NoSQL take some getting used to. Mainly- the convergence of certain principles into a single principle. The "Interface" is the "API" which also becomes the "Data Access Layer (DAL)" as it translates usable data into NoSQL. Altogether, they form a "Layer". Can you use the same code you've relied on for years to leverage these technologies? That is up to you, the developer, and how much performance you wish to squeeze out of the whole thing.
Top comments (0)