This is the first post in this series dedicated to ASP.NET Web Forms modernization and today, we will discuss data access layer considerations.
Join the DZone community and get the full member experience. This is part 1 in a series of blog posts dedicated to ASP. NET Web Forms modernization. The series expands on the topics discussed in the Migration Guide: ASP. NET Web Forms to Modern ASP. NET – a compilation of technical considerations for modernizing legacy. NET web applications, gathered from our experience doing many. NET modernization projects. Here is a list of all articles in the ASP. NET Web Forms modernization series: Coming up next (stick around!): Your business application is as good as your data. The impact any software system has on the business is directly proportional to the quality, structure and meaning of the data it gathers and organizes. That’s why we are cautious when it comes to data in a software modernization project. The data layer in any system is the stable foundation on which the application evolves. And no matter how rapidly you change frameworks, technologies and components, the data layer is the single piece in your system you must touch carefully. Modernizing the typical legacy Web Forms application brings many considerations across the application stack – how do I transform my back-end to modern. NET, how do I design and create the API efficiently, what type of front-end technology should I use? Preserving the fundamental capability of your application (and thus its positive value), however, essentially means you must continue providing the ability to access, process and analyze data the same way as before. Any slight change or missing feature in the data capabilities of the new system you design and your shiny new application is already less valuable to your users than the one they’re currently using. That’s the opposite of successful software modernization. You don’t want that. When talking about software modernization, everybody sees the project as an opportunity to do better, to fix old problems, eliminate existing limitations, and create a top-notch system design that would make any software architect proud. Naturally, technical leaders start having heated conversations about switching to better relational database technologies, going from a relational to a document-based database, or drastically changing the database schema to support that all-time requested feature that we could not deliver before due to the limitations in the current schema. At my company, we’re very cautious about the topic of data when designing a modern. NET application to replace a legacy. Our main objective – data preservation and reuse. All existing data sources, data structure and operations must be available in the new system; all critical system capabilities related to data query and manipulation – preserved. We have repeatedly seen that being conservative with changes at the data level is the best approach for meeting existing system capabilities efficiently. Improvements to data (schema and operations) can only come if the new system provides all data capabilities the legacy one does. The easiest way to think about data preservation is to ask, “Can the new system run independently on old data and provide all data operations the legacy one does?” If you can swap the old system with the new one overnight, and the user can continue with their business in the morning right where they left off – you have achieved data preservation and reuse. You preserved all the data without loss, enabling the same data operations as before. Your users are not worse off having switched to your modern application. Your system meets the table stakes requirements. As technologists, we realize there could be many ways to skin this cat. You could rewrite your entire database schema, change to a different RDBMS system, or rearchitect your data access code entirely and still provide data compatibility with your legacy system. We often do this early in greenfield software development projects – we experiment with different database technologies and data flow architectures and change them as necessary. However, in a software modernization project, time and cost efficiency are primary objectives for the overall project. Most often than not, going the long and costly route of a complete data re-architecture is not an option. As system architects and software consultants, we understand that the development time required to get to the baseline system capabilities (those already provided by your legacy system) does not add business value on its own.
