SOLID Asp.net Web API Project Organization for maintainability and scalability
I like to organize my Wep API projects using the following solution organization (Sorry for the ugly diagrams…).
Each circle in the diagram is a .Net project (or DLL) in the solution:
-
Solution.Global: The global DLL contains POCO objects and the public interfaces of all the others DLLs. All the DLLs have a reference to the Global DLL. -
Solution.IoC: The IoC project declares the bindings between abstractions (interfaces in Global) and implementations (Objects in each DLL). The code of this DLL can easily be re-used. -
Solution.WebApi: The Web API project is the composition root for the IoC and therefore it is the only DLL that points to the IoC project. -
Solution.DAL: The application data access layer. -
Solution.WebClient: The front-end application.
By using this separation we can follow the SOLID principles, for example I can replace the Solution.DAL DLL for a new one by just changing the binding in the Solution.IoC DLL.
The back-end projects and front-end projects only communicate to each other via AJAX and there is not C# or ASP at all in the front-end.
I feel really strong about this way of organizing web applications because I believe it is highly maintainable and scalable. For example, if in 2 years time Bootstrap or Angular become a legacy technologies
we can create a new front-end and reuse the 100% of the back-end. We could also create a new front-end application that re-use the same back-end reducing the amount of work.
If I the application is too complex I could add extra DLLs (Business, Helpers, PDF service…) to separate concerns as needed:
