.NET Beyond the Demos - Part 2 - The Architecture
In order for me to communicate this particular story, I first need to outline the overall architecture. At the highest structural level, the architecture is really quite simple. Let's start there and work our way down.
Part 1 - Introduction
Part 2 - The Architecture - This post
Part 3 - The DTOs
In order for me to communicate this particular story, I first need to outline the overall architecture. At the highest structural level, the architecture is really quite simple. Let's start there and work our way down.
Starting with the MVC Application. In our case, this is the legacy application. It is currently using Enterprise Library. Since this is an existing application, we can't just turn it off while we develop the new data access strategy. We have to have a migration plan. So we added a Web Api. Since this was a completely new piece of the architecture, we were able to choose the latest version of .NET Core to develop it in.
We created a repository library to contain the Entity Framework piece (as well as Entity to DTO mapping logic). We're currently looking at moving the mapping logic to the Web Api layer and removing the dependency on the common library from the repository.
Without going into detail, we have good business reasons for implementing our own repository on top of Entity Framework (which is already a repository). However, I will be unable to go into too much detail as that is proprietary code that belongs to my employer.
I may be able to get Jeff to write about it more on this website, but until then, it's pretty much off limits to me as I didn't write it and couldn't rewrite it for this blog without referring to the source code (it's also very complicated).
The Repository layer is currently accessing an Oracle database, but SQL Server is in our future. This has had an enormous effect on how we have architected the system. It's more generic because of the need to one day "flip a switch" and be on SQL Server.
The Web Api client that is used by the MVC application is written as a .NET Standard library so that it can be used cross-platform in UWP, Android, and iOS. The goals here were maximum code reuse and minimal maintenance requirements. We've tried to simplify the life of the rest of the team who will be responsible for replacing the Enterprise Library code with the new Web Api and "Wapi" Client code.
We're also planning a mobile app for iPad that will be used by over 200 users throughout the state (so far, more to come), so we've planned our architecture accordingly.
The current application does not make use of much JavaScript, so that's an area we'd like to explore once the Web Api is in place. Multiple single page applications will likely replace the server-heavy MVC implementation that's there today. The application is too large to be managed by a single SPA, so "mini" SPAs will have to be developed that work together to provide a cohesive solution.
Overall, I believe we have been successful in our implementation. We've had to make a few adjustments to our original plans, but the outcome has been very rewarding. We've already seen development times drastically reduced as the complexity of the day-to-day coding has been reduced.