One thing that has always bugged me about Entity Framework and other .NET ORM's is how they encourage not leveraging the power of the database. Instead, you get monstrously complex layers built on the Repository and Unit of Work pattern to handle transactions and such. This is what SQL Server, Oracle and most other relational DB's have been specifically engineered over decades of development to do very well. It's like buying a bloodhound and then trying to sniff out your quarry yourself while the dog sits on the porch.
Agreed.
Another thing that's hard for me to buy is the Code First approach. I think you need to know and take control over the database your app will use. There is a higher chance of changing your ORM or even the platform you are working on than your database. You have to know your database.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One thing that has always bugged me about Entity Framework and other .NET ORM's is how they encourage not leveraging the power of the database. Instead, you get monstrously complex layers built on the Repository and Unit of Work pattern to handle transactions and such. This is what SQL Server, Oracle and most other relational DB's have been specifically engineered over decades of development to do very well. It's like buying a bloodhound and then trying to sniff out your quarry yourself while the dog sits on the porch.
Agreed.
Another thing that's hard for me to buy is the Code First approach. I think you need to know and take control over the database your app will use. There is a higher chance of changing your ORM or even the platform you are working on than your database. You have to know your database.