Boilerplate is a startup template for ASP.NET web applications, both Single-Page or Multi-Page. With one click of a button we get a project structure containing multiple preconfigured modules and libraries in an NLayer architecture (Domain, Application, Infrastructure and Presentation Layers), and Domain Driven Design (Entities, Repositories, Domain/Application Services, DTO’s…).
What differs from the “classic” Visual Studio template is the ABP framework, which offers many features available “out of the box”.
Some examples of these are:
- Multi tenancy support;
- Repositories (that can be used as is without developing custom extensions);
- Unit of Work (application service can be decorated with a transactional aspect);
- Server-side validation (via data annotations or custom validators);
- Dynamic Web API controllers (automatically-generated web API layer for your application layer);
- Background Services (jobs);
- Real Time Services (SignalR integration);
- Localization (multi-language support with helper classes for both server side and client code);
- …and many more listed here
Module Zero is an additional framework offering tenant, role, user management, authorization and so on. I have not used it personally as it was immature at the time we started our projects.
The good thing is that you are not forced to use all of these features! You can mix and match and take what you need, but I think once you get into the framework you’ll prefer to stick with what you get. More about this later.
The current state (compared to what it was before)
I haven’t used this library since 2015 and I’m amazed how many new features have been developed since then (like Background, Real Time Services and Timing System, which we implemented on our own)! They actively add new features to both the open-source framework and its premium counterpart, which is called ASP.NET Zero. The latter is marketed as an “enterprise startup template” with active support from Volosoft (it even has a separate web site!).
When to use
Personally, I’ve observed that it’s best used for relatively small (targeting rather tens than thousands of users) and simple web sites (with no special constraints on Web API standards or authentication protocol) that need to be delivered to the market in a short time by developers of mixed backgrounds or skills 🙂
This was the case for our two projects, where we had only 3-6 months to deliver a complete, working application. Moreover, we had limited experience in SPA applications, except for the MVVM knowledge from the WPF app we had worked on before. ASP.NET Boilerplate did all the “nuts and bolts” to have the server-side application layer working with the client-side Angular pages. It was very easy and efficient to concentrate on business logic and customer needs rather than spent time on cross-cutting concerns like the Web API controllers’ syntax, Angular modules loading, localization (this benefits us now as we need to add Spanish language support to one of our ABP applications), etc.…
When to avoid
- Whenever you want 100% control of your code and the libraries you are using (and want to know what you are doing).
- For very complex web sites, when you need to adhere to certain REST standards for your web API or have some custom / special authentication / authorization needs. Of course, you can still achieve your objectives by customizing the framework, but this may be counterproductive. It’s better to start from scratch and build the web site by yourself.
- In complex deployment scenarios (like cloud). This is because debugging of dynamic code or validation interceptors may be cumbersome.
What I’ve learned
This is nothing new or ABP-specific, my observations would probably hold true for other projects/frameworks 🙂
- You need to spend some time on tweaking the template-generated code to adapt to Objectivity coding standards.
- We don’t like ABP coding style for Angular views, controllers and services – we refactored them in accordance with John Papa guidelines.
- It’s good to start with resources and localization helper classes from the start if you are thinking about multi-language support.
- We struggled to get Date Times normalization between client and server in different time zones. We implemented a custom Clock provider which was later included in the framework.
- Early implementation of ABP (2014) did not have a “Null” Unit of Work concept that could be used with application services with no database-level transaction needs. It caused run time exceptions, but luckily I was able to implement the appropriate class and extend the framework easily. I raised this issue on the ABP forum and it was quickly included in the framework.
- I had a few issues debugging the ABP code in the Azure environment, particularly in respect of the Identity interface implementation where we inserted a “thread unsafe” code (to get user details from the database). The error could only be reproduced in Azure, and because of this we spent a lot of time identifying the root.
- We had also a few issues with multiple versions of the same library across projects – Log4Net if I remember correctly. For some reason the ABP could use the same version across all projects/modules.
To sum up, ABP is best used for relatively small and simple web sites that need to be delivered with short time to market by developers of mixed backgrounds or skills. Whenever you want full control of your code and the libraries you are using, you should avoid ABP. This led to it being rated with a Trial mark in our 2016 edition of Technology Radar.