In a banking scenario with high transaction volume Code First can be higher than Database First or vice versa?

Asked

Viewed 73 times

1

I am architecting the development of a backend structure composed of microservices for a financial institution. Probably the biggest project I’ve ever worked on, and I’m having serious doubts about using Code First or Database First. We will use ASP.NET Core 3 with Microsoft SQL Server, all hosted on Microsoft Azure. This is an application that due to some business partnerships may already have a few million users guaranteed.

The practicality of the Entity Framework Core would be very interesting, mainly due to the speed in the development process (we have a tight timebox)however I have concerns about performance with queries automatically generated by the framework in an application with so many users.

In contrast a ORM seems to be something interesting when we don’t have all the business rules mapped out yet, and the database needs to track the progress of the application. I imagine that the Migrations of EF Core could make the process very practical, mainly because I am thinking of working with microservices.

Is there any material or whitepaper regarding the use of these techniques for high-volume applications? I am particularly leaning towards the use of code-first. There may be some obstructive reason in the mentioned scenario?

c# database .net entity-framework software-architecture
  • 5

    If performance is a ORM concern it shouldn’t be used, right? You need to choose which of the two to use. Core only has Code First, what you can do is import the DB model to write the code for you, but it still works as Code First. Its use makes a difference, the model not even because it is only a model of development and not of execution. Microservice can even scale up (almost always no need - you’re using one of the 30 most accessed sites in the world that runs monolith and can run on 1 server) but it slows everything down, and absurdly hard to do right, it’s horror show

  • I work with banking systems and micro services... I can say that any ORM is "banned" and most follow the CQRS. But... it depends on which operation is going to be done and which database... Here the set of solutions include Mongodb, SQL Server, Redis and etc... all of them on-premise and in the Clouds...

  • @Leandroangelo Thanks for the input. Do you work with the database first approach? What’s the main reason you banned ORMS? Is there any material, white paper or book that you can suggest me to better understand how DB-level operations are performed in this segment? I’m still opting for microservices because it can help a lot in our time to market, but I plan to use SQL Server to store all transactional user records. If you like, structure it as an answer I’ll gladly accept.

  • Basically the problem with Orms is that you are not 100% in control of your queries, transactions and modeling (code-first). There is no cake recipe, only good practice, but every need is a case. And in the end you will be restricted to the paradox of the theorem of CAP https://medium.com/system-design-blog/cap-theorem-1455ce5fc0a0

1 answer

0

In my view, the advantage of using Code First is of course productivity gain. However, the problem is that this strategy opens gaps for developers with little knowledge in databases to model entities so that they will reflect in tables and relationships inefficient in the database.

On the other hand, the advantage of using Database First is that database modeling tends to become much more efficient. However, depending on how the database is modeled, queries tend to become more difficult to write in the Entity Framework.

Personally speaking, I see no problem adopting Code First, as long as you’re working with a more senior team, that knows what’s being generated in the database and anticipates the bottlenecks when the data volume grows.

Of course, the use of pure SQL performs better than the Entity Framework, but this difference is usually insignificant in CRUD operations. Of course, pure SQL performs much better than Entity Framework in the most complex queries, but you can get around this problem by modeling the database so that queries become simpler.

Regardless of the strategy you choose, the problem is that because it is an application with the potential to have a few million users, maybe the big question should be -SQL or Nosql?

Browser other questions tagged c# database .net entity-framework software-architecture

You are not signed in. Login or sign up in order to post.