Almost all modern software is written in tools that are not relational, which is the design of a preponderance of database engines. Working in procedural code such as COBOL, PL1, RPG you don’t speak SQL. Using vector based languages such as R, or data warehousing tools using Cubes, again there is a dissonance between the relational configuration of data and the client code. Object oriented languages can adapt relationships into objects most time, but that is not really the goal of your program.
Why not use an interface that can talk to any form of storage, translating one stream into that of another? Pie in the sky? Maybe. But, if your application has a lot of external resources it can be worth the time.
The architecture is simple. There is a standard interface for your data. You then create an adapter for any data source with which you wish to interact. One source may be user entered data from a web site. Another may be a relational database. A third may be some third party product supplying data. It doesn’t matter if the data is persisted, or only lives in memory. The point is that you can write an adapter, to convert the data to or from your single master interface.
The goal is to have simple objects that carry only data such as STRUCTs, POCOs, or JSON. A interface or abstract controller is designed with a standard set of functions able to execute with inputs from these data structures.
Now you can begin some tightly coupled software such as Entity framework. An adapter can be written against entity framework, implementing the centralized interface of functions. It takes input and saves. It retrieves data from the database, and returns the standardized data. The method calls all come from the interface.
Now when I want to change my data storage to Mongo, all I have to do is write an adapter for Mongo, using the exact same interface, implementing all methods. If I wish to integrate a third party tool, I can again implement the interface with an adapter specific to that product. This model is well suited when you need to send data to multiple destinations, or copy data from one stream to another.
The primary goal is to remove tight coupling where it provides no value, and maintain the efficiencies of code generation, restricting tight coupling to a single adapter.
Would you use an architecture like this? Share your thoughts in the comments. Don’t be shy, or afraid to disagree or challenge the concepts.
Cheers,
Ben