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.

The 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 Abp be integrated into my project? Should I produce a mirror project structure that includes the corresponding base Abp version for each Abp-defined layer?
  • At the very least, studying the ABP would provide valuable insight into how these architectures work. Just make sure you don't run out of oxygen. Sep 26, 2014 at 16:07


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.