Data Access Level Design

Question

I ran into a design issue regarding the design of my DAL. As we all know, in its most basic definition, DAL means a layer that is responsible for communicating with some data warehouse (of course, I'm not talking about a repository template), usually a database. Now this is where the catch is. Some of our business objects will need to get their data from the database, and some of them will receive data from other sources, i.e. Web services. Some of our team members suggested that BO should be smart enough, knowing whether to call DAL (who knows only to talk to the database) or call the required web service. Others suggested that this may not be the optimal solution, assuming that everything should go through the DAL, where it will contain valid adapters or something else for each data extraction method.

How would you create a system with such data access needs? Is any of the proposed solutions good enough for the long-term (the second may take longer to develop) or do we need to take a completely different approach? Perhaps there is a design template that is suitable for this kind of problem ...

Thank you Avi Shilon

Answer 1

I would highly recommend the second approach. Business logic should not know anything about a data source.

When he does not know, in addition to the usual advantages (simplification of maintainability due to isolation and cleaner design), you also have flexibility (depending on how well your DAL is designed):

• As stated in your minimum requirements, retrieve data from different data sources

• Retrieve data from a priority set of data sources to achieve failure.

  eg. you get the latest price quotes from the Reuters citation service in real time, but when it breaks due to problems with the WAN, you return to the alternative service or the older prices cached in the database.

  Obviously, data sources are ordered by priority of non-increasing quality and consistent reliability.

• Retrieve data from a priority set of data sources to achieve caching

  eg. get the price from the local cache, if it is absent, get from the local database, if not, a request from the service provider.

In addition, just to give an example of more convenient support, if your data source changes from a real-time query service to its own gold copy database filled with a push channel from a provider, you only need to change the DAO instead of each of the many BOs. who need data. It’s easier to change and safer to test and deploy the changes.