Object-relational mapping (ORM) framework offers a code-first approach as a viable option to model data structures. By reducing a step in developing a business application, the code first framework promises an efficient way to build software without much hassle.
But it has its advantages and setbacks. In this blog, our team highlights some of the hazards of the code-first approach.
Let’s first understand the topic in focus.
What is Code First?
Traditionally, when you build an application, especially a business application, you consider the data structure. You would develop a database with the help of a team with different skills that together build the code, which later gets checked and run. We use two different ways to conceptualise the environments we are trying to formalise with software.
So here we have two worlds involved in the whole process of making an application:
-
Relational Model: It is a framework for describing a domain. It works with the database structure, its code, and data at rest.
-
Object Model: The second one makes the application code. It consists of the visual representation of the application.
We need to check the maintenance of these two worlds together, but separately. Both these models have their strengths and weaknesses when conceiving any given domain. Back in the day, when developers used to work on projects that required both of these landscapes for modelling, it gave rise to what computer scientists call impedance mismatch (problems that occur due to incoherence between the database and programming model). All of this can bring in a lot of trouble.
Even if the application gets built with minimum impedance mismatch, problems will arise when the time for modification comes.
Then came wireframes that made it easier for the developers to access the database from the code without knowing the database. Such frameworks evolved further, and now the code could get translated into the database structure.
Maintaining two separate worlds for database and application code soon vanished with this discovery. The wireframes took care of the database by taking care of the code. Now you only have to work on a single world, and that is what you call an enticing idea.
The code first methodology started with this idea and took advantage of the technological evolution. It acts like a sledgehammer, making different modelling domains opaque to the software developer. So, instead of having two separate working environments, the developers only need to work on an object modelling environment (OME).
In simple words, if you are using a code-first framework, you are going to define the business environment using a single modelling language, which will be an object one. And the code that you will use will try its best to translate your modelling commitments into the relational space or the space you are using.
With the need for two separate teams to create an application gone, the slogan became ‘just start coding’. Build your objects and database repositories that hold those objects, persist those objects, and everything will magically come into existence.
Understanding Through an Example of How Code-First Model Works
Let’s say a publisher comes to a developer where they need a new system for tracking books and authors. The old way to build the system would be to get a business analyst (BA) on the project and create a canonical information model of the books and authors. Afterwards, this canonical model gets shared with database and application architects. Both the developers will then recapitulate that model in terms that could get used for building a database and in terms that get used for building the application layer. So inherently, both the database and application architects talk about the same thing, but one is working in dot net and the other in SQL.
The code first says the BA still goes in and develops the canonical model, but shares it with only one architect. That one developer will recapitulate the model in an object environment. And then, a code-first framework will build the object model in a language that the persistent database, often a relational or an object database, can understand.
The Hazards of Code First
Code first frameworks often get used in smaller projects, and sometimes companies extend them to large-scale projects, which is hazardous. But what happens in smaller projects is that business owners often directly put a developer to work on the project without any prior analysis by a BA.
Due to the project being at a smaller scale, the developer goes head in first and starts coding. The developer builds the objects that represent the application’s needs.
In the midst, the developer and business owner forget that the application is a model of the real world. The transition from a real world to a virtual one is best done by someone highly skilled. A developer and an architect fail to do that as they get trained in substantiating a model in digital space. On the other hand, an analyst understands how to alter a real-world model for digital space and brings that model to the developers. So a significant hazard of code-first becomes ignoring business analysis and rushing to the developer.
The second hazard is system performance. So, the code-first framework often implies that there is an object-relational mapper (ORM) in the mix. The code-first provides the developer with the opportunity to work in only one modelling environment, OME. It means that we are relying on some forward-looking piece of software to be writing queries.
At DOOR3, we have helped many clients who have already embarked on a code-first application project, built something, had it accepted into production, and then only to see it come to a halt. On inspection, we have seen that the SQL was written in such a sub-optimal way by the code-first architecture or ORM that we had to go in and replace it with hand-written code. So, performance is another element we need to watch when working with code-first.
All of this can also lead to the maintainability of the performance. Though code first is easier to work with, one thing that frustrates a lot of developers is that there is no tool present in the ORE in terms of tuning the application. Everything gets done through ORE in the application. The moment you begin unilaterally making changes at the storage level, you can break the ORM or limit ORM from that section of changes.
Wrapping up
So, here we discussed what is a code-first approach all about and what are some hidden hazards behind it. Even though the model has some efficiency issues, it still works great for building small-scale applications and driving growth. If you wish to know more about our services, contact us.
