There has always been a constant struggle on how to organize core or infrastructural projects in my .NET solutions. See, I started back in the day of the Composite Application Block (CAB) and with the early version of the Microsoft Enterprise Libraries from the Patterns and Practices group. Ten years ago when you created a desktop solution using the CAB template you had an organizational structure that contained infrastructural projects like so:
With modules looking like this:
These modules use services defined in Infrastructure.Services but via dependency injection. Over the years, this pattern has influenced the structure of my past and current solutions.
While I do like the pattern, there has always been a persistent challenge of determining what goes where? The original premise of Infrastructure.Dictionary was to contain all business entity definitions or what we we call the business model. Infrastructure.Interface was supposed to contain service interfaces the idea being that these two projects together define the system API. What ended up happening as the solution became bigger is interfaces and UI elements started creeping into Infrastructure.Dictionary.
Recently, I decided to rethink this approach of having two separate projects:
All modules that reference Infrastructure.Interface, must also reference Infrastructure.Dictionary. In a solution containing 30 projects, there is a single project that references Instructure.Dictionary and not Infrastructure.Interface. This project which contains symbology editors for points, lines and polygons cannot be used deployed on its own,therefore, it must be deployed within the same process space in which Infrastructure.Dictionary has been loaded. Does it make sense to continue separating Infrastruture.Dictionary and Infrastructure.Interface projects. Should I just have a single project called Infrastructure.Core?
What are others doing?