Refactoring our architecture
After a long meeting with Ken and Roee about our(SQLink R&D department) architecture, I decided to put it out on the table – maybe you can give us some better insights about some questions we brought up during our session. I’ll start from the end of our session – this is the architecture design we thought about:
Before I’ll start:
We’re generating our code (as much as we can anyway) which means we’re working in dual mode – “Data\ERD Driven” development for trivial data-access work and pure OOP development for our infrastructures\services. The generated code uses our infrastructures\services according to its needs, of course.
That was important to specify as some of our architecture decisions are made according to this development model.
So what’s the difference between this architecture and the one we had before ?
Old architecture:
- The GUI (Graphic User Interface) talked only with the BL (Business Layer), even for data-operations which were NOT business (or logic, for that manner) at all.
- The Business Layer was responsible to wrap any call to the Data Access Layer and publish any exception (if occurred).
- The Business Layer was auto-generated but was “table based” instead of “context based”, i.e – there were directories for each generated table and in each directory – the relevant classes for wrapping the DAL(Data Access Layer) calls. This caused our Business layer to become a “Data Gateway” instead of clean business logic layer as it should have been.
- The business layer was pretty massive – think about generating 80 tables. This means 80 directories in the BL project for 80 “Data Gateway” operations. Any real logic was hard to detect.
What we’ve changed:
- It was crucial, for us, that the GUI will be “aware of” one layer only. The application shouldn’t “know” if the given data is logic based or not. Its only purpose is to present data, that’s it.
- With this in mind, we wanted to make a clear separation of our “Data Gateway” and our “Business Logic” services. Application Gateway layer was born.
- Application Gateway layer is now responsible for wrapping any calls to the DAL, BL or any other required services. In addition, it is responsible for publishing any kind of exception which occurred in any one of the underlying services (including DAL & BL). The directory structure is now:
- ApplicationGateway.Data.[Table] -> under each of the tables there are the required classes for clean data operations (CRUD).
- ApplicationGateway.Logic.[Context] -> the required classes for each logic context.
- ApplicationGateway.Data.[Table] -> under each of the tables there are the required classes for clean data operations (CRUD).
Open note:
With the new architecture in mind, we had some open notes which were answered but maybe could have been handled better.
With the new architecture in mind, we had some open notes which were answered but maybe could have been handled better.
The Application Gateway is now a manager\wrapper\sometimes facade class for our services and is responsible for communicating between the layers, is it completely true ?
A scenario:
The Business Layer needs some data in order to do some logic stuff. It makes sense that the Application Gateway will query the DAL and then will send the results for the BL method so it will be able to do the logic stuff with ease. But what happens if the BL method needs different data according to the inner logic.
Solutions:
1. We know the entire process of the BL method – so we can send all the data, even if some of it will not be used. BAD.
2. We can send delegate(s) to the BL method so the Application Gateway will be raised if any other data will be required. if so – the AG (Application Gateway) will be responsible for communicating with other services and return the required data back to the BL method. This is good decoupling but requires harder maintenance and development as the BL method could potentially required different delegates (signatures) – requires experienced programmers.
3. We can put a reference between our BL and the rest of the required services. In this case, if the BL method required data from the DB, we will add a reference to the DAL, create the required object and get the required data. This solution is easier for maintenance and development (requires less knowledge by the programmer) but create some coupling between the services.
2. We can send delegate(s) to the BL method so the Application Gateway will be raised if any other data will be required. if so – the AG (Application Gateway) will be responsible for communicating with other services and return the required data back to the BL method. This is good decoupling but requires harder maintenance and development as the BL method could potentially required different delegates (signatures) – requires experienced programmers.
3. We can put a reference between our BL and the rest of the required services. In this case, if the BL method required data from the DB, we will add a reference to the DAL, create the required object and get the required data. This solution is easier for maintenance and development (requires less knowledge by the programmer) but create some coupling between the services.
Our decision:
We decided to go on solution #3 – better trade off.
What do you think ?