Converting legacy applications using Code First approach.
C#, ASP and Entity Frameworks
While consulting with Regional Center, RC, to track special needs adults, I looked at different approaches. They had a Frankstenstein situation of using office applications to track their clients, day programs and social workers etc. Their needs outgrew their software. There were two approaches to development: Database approach or Code first approach.
What they needed was a web application that could manage, maintain and track the history of special needs adults. This would provide better insight and improve services for their special needs adults, which they refer to as clients.
Their data sources included sql, ms-access and excel spreadsheets. Their software worked for their basic needs previously, but the poorly designed databases needed to be updated. I chose a modern approach of code first over a database approach. Why? Let’s exam both approaches.
Database first approach
The old way of the database approach was to design the table. Once you design the tables, Entity Framework would generate domain classes. Without Entity Frameworks you’d have to code everything by hand. Yes, that’s how I used to do it. I would go oscillate between the sql database, stored procedures, VB and C# Components all the way to the HTML and ASP scripts That’s how I understand the architecture so well.
Many of the sql tables that were needed were: clients, social workers, medical history, work programs, group homes, day programs, etc. As you can see there were about 25+ tables that were created.
The biggest hurdle is being maintainability.
How do you synchronize the local, test and prod db’s?
Changes in the local db must also be reflected in the test and production db without breaking any tables, records, and stored procedures. There is a lot of room for mistakes. What is needed is a mechanism to compare and update different db’s. A more manual approach of creating scripts is needed. I used to create table, view and stored procedure scripts.
Maintaining migration sql scripts can be a waste of time. Focusing on domain classes which is much faster.
Code first approach
The modern way is the code first approach. Create domain classes in C# such as client and group home client. Then allow the Entity Frameworks to generate the necessary tables. Then abstractions are created to load the data. With the Entity Frameworks tool, this eliminates the process to touch the database. Thus allowing coders to simply code.
Keep in mind that every time we want to make changes, we start with the C# code. Run the data migration unit and the database will be updated. A few tasks only need a one-time setup. such as context, db connections, and enabling migrations
Any changes in the objects can be taken care of using add-migration. That’s it!
A key benefit is that there is no sql; therefore, it’s not version dependent. Based on our model, it can figure out how the database should like.
When coding first, I treated it like github. Make small changes to the C# code, then add to the migration database. This creates a better version to track. Then I’d give it a meaningful name to the migration.
MYTH
Database first gives you more control over your ms-sql database. That’s simply not true. Let’s say you wanted to create a trigger, a modify a query behind a view, remove a stored procedure. You can do that all in the code first approach. Some have said that I reverse engineer and use the legacy data.
I also used in the web application for Book-Beats for the High Plains Book Awards.
Summary
Coding First increases our productivity. We don’t need to design our time with table designers. We know what data we want and how to access it. It’s much faster to write code: Coders love to code. Coders prefer that over design and a lot of mouse clicking, Also note that a couple of steps are one and done.
