A short story about renovating a legacy code project and making it fun
Legacy code can be awkward to work with. Technology is progressing so fast that things worked with just few years ago are now out of date. The project that my team works on was primarily written in ASP.NET MVC with DevExpress Web Controls and EDMX Database-first approach. We decided to refresh it, clean up the underlying architecture, and migrate it with the view layer to React.
Only a couple of years ago I worked in an ASP.NET MVC project featuring KendoUI controls and a jQuery-style frontend. Back then it felt so great to work in these nice, new technologies. These days React and Angular are on top. Nobody wants to do plain jQuery anymore, not to mention heavily backend-dependent controls like Kendo or DevExpress.
I enjoy working with the latest technology stack, so I wasn’t convinced about ASP.NET MVC project with DevExpress and EDMX Database-first approach. But, along with three new software developers full of fresh ideas, we decided to face up to the challenge!
ABOUT THE PROJECT
Before presenting the renovation steps, I should mention how the project looks like from the business side. It is quite a big platform, consisting of many smaller “apps” that are used to generate, process, and present certain sets of data.
The data can be associated with each other linearly or as various types of diagrams. It can be added, removed, modified, and inserted into containers—all this within certain business rules. Some data is presented on diagrams (using GoJS library), other in the grids and spreadsheets.
The end users are employees of organizations that use this software to control their staff, assets, business processes, etc.
Until now, every new app was set up from the prepared template: an ASP.NET Controller, a set of Razor views, and a template for plain old jQuery-style single page application, which was written in ECMAScript 5 and later bundled with Gulp. These would usually talk to the service layer, which then talked directly to the Database or to the Very Old Business Logic (VOBL), that was usually treated as a black box.
The project was functioning and earning money; after all, it was already used by a great number of end users. However, when we saw the code and the tech stack we decided that it is time for revolu…erm…renovation!
THE RENOVATION: PART 1 – VIEW LAYER
We decided to start from the top. Neither developer wanted to work with DevExpress, especially as DevExpress has its younger sibling, the DevExtreme, with quite an advanced React Grid. We decided to take a deep dive and go for React.
It was a bold decision but the client gave us a single 2-week sprint to create a Proof of Concept. And we did it! It was not an easy undertaking, but step by step, control by control, we rewrote an app that was quite simple and had a few upcoming upgrades waiting in the backlog.
All the sudden we had nice, structured ECMAScript 6 code, transpiled with Babel and packed with Webpack. And all this talking to the new, fresh WebApi.
I presented the Proof of Concept to the client just two weeks later. He was absolutely amazed by how smoothly and how fast the application worked. He was surprised but we knew that it would work that well as the DevExpress controls made server callbacks with almost every click.
THE RENOVATION: PART 2 – SERVICE LAYER
Having such a nice and fresh view layer it would be a shame to use the old and cluttered services. Firstly, we separated the old services that were inherited from an ugly BaseService class. What’s even worse, the BaseService class contained the DB context, which the derived Service classes were shamelessly using.
We created a brand new DB context unaware Service Layer that our WebApi Controllers can talk to. But what about the communication with the database? Well, here comes part three…
THE RENOVATION: PART 3 – DATA ACCESS LAYER
The whole platform is operating on different kinds of data, in numerous and varied configurations. Moreover, the data can be inserted into diagrams, can be associated with each other, and can be inserted into containers. The plain old Repository Pattern just wouldn’t work here. We had to think bigger.
We have decided to go for CQS – the Command Query Separation Pattern. The apps within the platform can query all they want from the database (within the user’s permissions of course), but the data modification logic is separated and closed within the Command layer. We have added additional support for Transactions, as the save operations often affect multiple tables.
SUMMARY
There is still a long way to go but, after few weeks of renovation, the project is definitely much more fun to work with. We still deal with legacy stuff from time to time, but it’s incomparable to the prior situation.
If I was asked for a conclusion, I’d say: treat your project like your house. Give it a fresh paint, put new pictures on the walls, and add a few pieces of new furniture from time to time. I guarantee you will see a difference (and so will your client)!
Looking for more tech insights? Check out the rest of our articles about software development!
