Using Dapper has made it difficult to change the database #126
-
|
Hi Kamil, First of all, thank you for your exceptional work. I think by using Dapper for queries in your project, although it is known as a lightweight ORM, It's coupled the code to SqlServer syntax and has made it difficult for changing the database. For example, using Oracle as DB. Am I right? And why not use EF in queries too? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
|
Hi @m-khooryani, i'll try to answer your question. But there are not good or bad architecture decisions: all of them have pros and cons. To make a decision we should first understand what is important for our system. To answer this question we have to specify and prioritize Quality attributes - non-functional characteristics of system like performance, availability, security, scalability, maintainability etc. There isn't ideal and universal solution: most off them are trade-offs between those attributes and we should always chose which are more important for us at the moment. CQRS allows to separate read and write models. Their goals are completely different and separation allows to use different approaches, patterns and tools for these models. For reads performance is the most important and Dapper provide it. Usage of views allows to abstract DB's details and make queries even more simple to develop and maintain. On the other hand write model is implemented with DDD and EF helps to create incapsulated domain model. So proper tools are used for different goals. Most of these ideas i read in Kamil's blog(and i hope i understood them right :) ) so i higly recomend to read all articles. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @m-khooryani, You can use EF for reads. But you need to be aware (if you want to apply CQRS correctly), that you should map them to a different set of models (data models), not to write models. So if you use EF to implement reads as I described above this is good solution and what to choose is a matter of choice. In my opinion, the architectural driver for EF will not be "maybe we change database in the future" because it is very rare situation and even when it needs to be done, it will be a lot of work. ORM is a Leaky Abstraction so you will always depend on database in some level. And I am pretty confident, that EF database providers works different in some scenarios. In my opinion, most common scenario when ORM is selected is not "future database change" but the team without good SQL/database skills and experience. So the team wants to abstract from database (instead learning) but sooner or later problems will start appear. This is bad - as a backend developer knowledge of your persistence storage at good level is a must-have. I don't say that raw SQL is better. I used ORM for query side in one project and it worked great. However, I prefer to have a full control of statements which are executed on database so more often I choose Dapper. Moreover, I know that some people use hybrid solution - they use EF to simple queries and Dapper for complex - I think it is a good approach too. |
Beta Was this translation helpful? Give feedback.
-
|
Could you tell which aspects of persistence storage you consider must-have for a senior backend developer? |
Beta Was this translation helpful? Give feedback.
-
|
Database design, advanced querying and stored procedures implementation, performance optimization, reading exeuction plans, general database systems theory (ACID, normalization, denormalization), proper type usage, troubleshooting |
Beta Was this translation helpful? Give feedback.
-
|
In Inspirations and Recommendations chapter of the project's readme i didn't find any resources about this subject. Could you advise some? |
Beta Was this translation helpful? Give feedback.
-
|
I read about relational databases and SQL a long time ago but If I could recommend one book It would be https://www.amazon.com/Microsoft-Server-Bible-Nielsen-Paperback/dp/B011DBKT5K . It is an old book (samples are for SQL Server 2008) but it is really a bible (above 1600 pages). It covers almost everything 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Hello Guys, I'm happy to follow this great project and observe the questions and answers that make me think about it. I'm working on a project that I use Dapper to query and there is an abstraction to acess the database, and two implementations, Oracle DB and SqlServer. I think it's not a problem change database and using this ORM. SAP I will open my first PR. |
Beta Was this translation helpful? Give feedback.
Hi @m-khooryani,
You can use EF for reads. But you need to be aware (if you want to apply CQRS correctly), that you should map them to a different set of models (data models), not to write models.
So if you use EF to implement reads as I described above this is good solution and what to choose is a matter of choice.
In my opinion, the architectural driver for EF will not be "maybe we change database in the future" because it is very rare situation and even when it needs to be done, it will be a lot of work. ORM is a Leaky Abstraction so you will always depend on database in some level. And I am pretty confident, that EF database providers works different in some scenarios.
In my opinion, …