SOLID 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:

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:



Now read this

Introducing InversifyJS

A lightweight inversion of control container for TypeScript & JavaScript apps A few months ago I started to think about the possibility of creating a requireJS TypeScript fork in order to add dependency inversion (DI) support. After... Continue →