Currently, the architecture used in the project is like a typical layered architecture, learned from PetShop. At that time, I thought the business logic could not be changed, so I removed the IBLL layer, but now it seems that this layer is quite necessary. When you look at the same thing, you will have different opinions.
The UI Layer mainly collects and displays data.
The Model layer mainly contains some anemia entities.
The BLL layer is mainly responsible for processing business logic.
IDAL is the data access interface layer.
DALFactory is mainly responsible for constructing data access objects. Reflection is used to create objects.
The DAL layer implements the data access interface.
The benefit of this layered architecture is that the responsibilities of each layer are clearer. At the same time, because data storage is processed through interfaces, multi-database support can be achieved theoretically.
This architecture is sufficient for general projects.
However, you will find many problems after careful analysis:
- There are too many dependencies between layers. The Model layer is referenced by almost all layers except DALFactory
- Although the architecture can support multiple databases, if the project is created to support multiple databases, the workload will be too large.
- Generally, a project contains multiple modules, so that the code of each module is mixed together. When the module is to be split or transplanted to other systems, the code of each module is coupled, poor separation.
- This factory class is also quite tangled. If you use custom configuration to complete the configuration, you need to write a bunch of code. if you add the Code directly to deleetting, then a bunch of keys.
If I have to design it again now, I will adopt the following Architecture:
- Put the code of the model layer, IDAL data access interface layer, and IBLL interface layer into a project, which is temporarily called the module Core layer, that is, the Core layer.
- There is an independent core component, including the factory, persistence layer framework, log, cache and tool class for creating objects.
- Dependencies between modules are solved through interfaces.
In this way, the portability of each module is enhanced.
It is better to have such a function, like in CSLA. For example, if a windows client is created, you can directly connect to the database for operations or perform operations when connecting to the Web Service, you can also connect to Remoting for operations. You only need to modify the configuration for the switchover, but you only need to write a business logic and do not need to forcibly reference the Web Service in the project, this is more perfect.
What do you think?