Going by the general principle of data abstraction, I normally abstract data in a serialized format(JSON) and pass it as a parameter to the Business Logic(BL) modules such that the BL module always see a consistent format of the data irrespective of the underlying data storage layer. Even if I use a ORM, I use the serialized format of that ORM. I feel I have the following advantages.
- By serializing data, there would be better control over data and parameters
- Any developer can write BL without thinking too much about the underlying data storage
- Wrappers can be written for new databases (There are a lot of ready-made wrappers to convert data into JSON)
- Testing could be done ruthlessly and without a database (since the data format is serialized)
- Functionally easier to understand and better OLAP, OLTP integration
I also notice the following drawbacks
- A new layer to be added between the database and the BL module (most ORM's nowadays come with a predetermined JSON format)
- Extra function calls slow down the application (but I think this trade-off is OK when compared to better testing and easy maintenance)
- Increased level of abstractions may confuse the developer
I make the above observations mostly in the context of business applications To follow this discussion, lets have an example so that things could be discussed in its context. Assume a product database having the columns: Product,Rate,Taxes and we need to create a invoice
Code without database abstraction
GET rate,taxes for product X from database multiply qty with rate and add taxes display invoice
Code with database abstraction
GET rate,taxes for product X from database Convert it into JSON call create_invoice function //This does all the calculations display invoice
In the second example, I would pass arguments in the form (Product=X, Qty=5, Rate=5, Taxes=0.05). If taxes are to be split into more that one category (State Tax=0.03, Central Tax=0.02) or a discount factor to be added I would just increase the number of parameters in the BL functions such that the database fields, the JSON keys and the function parameters match (this is done automatically during serialization and most ORM's do it). This makes it easy, in my approach, to extend functions and also make modules independent of data since the modules always know the data they can receive and even if they receive a new parameter, they can adapt it provide the underlying code is intelligent.
My general questions are
- Is this a good pattern and what's it called (Data abstraction comes to my mind)?
- Pros/Cons of this pattern(apart from those mentioned above) in the context of business application, apps for embedded devices, big data
- Is there a difference between this pattern and ORM (I believe so since ORM is mostly a class wrapper to get data from a database while this pattern is more oriented towards data structure)
- If this is good, can this be easily understood by a new developer?