As I finish one project and start another, I have a small time window to come up with an architecture for the new. I am coming from the following design:
- Web application
Receives domain models & DTOs, Sends DTOs
application configuration, application-specific DTOs+mapping, application-specific services, & controllers)
- Core library
Receives entity models, Sends domain models & DTOs
domain models+mapping & repositories, entity mappings, DTOs+mapping & services, vendor-specific interface implementations like ASP.NET Identity, anything else we want
- Data library
Receives input from database adapter (ODAC in this case), Sends entity models
entity models, specialized company data context wrapper, useful code representations of schema, extensions for parsing response from database
- Infrastructure library
Receives nothing, Sends nothing
Common interfaces, adapters, wrappers, extensions, and other things used in all projects
These layers were not initially segregated but became so when things got messy. Each segregation took significant refactoring time. Even once all were segregated, there were still some design issues:
- Tight coupling with vendor implementations like Castle Windsor, AutoMapper, and NLog
- Awkwardness and difficulty of generic repository implementations
- Duplication of (container, action, etc) logic in applications
- Difficulty determining the order in which processes flow & services should be called
As I see it, the final project structure was more than adequate to support a well-designed architecture. The final product, however, was not designed as well as planned. So I'd like to start out with a more definite architecture this time.
The big change would be to abstract out every substantial implementation so that direct calls to things like AutoMapper or NLog are unnecessary. This would require a commitment to depdency injection and implementation of some DI system and/or IoC container. Abstraction will require avoidance of direct inter-layer dependencies, which results in a more granular project structure.
The granularity is helpful to someone at my modest skill level. It forces me to consider where each new component belongs. The problem is that I may not know the optimal set of buckets (taxonomy of projects and their components) to standardize.
Abp library seems like a promising way to get started. It provides so much abstraction that a direct dependency on
Abp would be at least 1-to-1 with any structure I could design. It would definitely provide a solid foundation and course for development.
My main concern with implementing
Abp is the potential for over-engineering and/or wasted time implementing such a rigid framework.
My first question is:
- Is it worth it to use
Abp? How is that based on personal experience, if at all?
Given that it is worthwhile to embrace
Abp, I would also like to know:
- How should
Abpbe integrated into my project? Should I produce a mirror project structure that includes the corresponding base
Abpversion for each