There are some similar questions I've found here, but none of them fully answer the question I'm asking. Similar questions: here and here
In my company, I develop C# .NET applications and our Server Admins in IT don't allow direct table access so we're required to use stored procedures to insert, update, and delete from a table. In the past I've been using DataSets and TableAdapters to access the tables of a database, but I'm starting to realize that everything is starting to use Entity Framework.
Herein lies my issue. There is another developer here that uses the Entity Framework, but he doesn't actually use entities. He uses Entity Models that have no tables or views, only stored procedures. Doesn't this defeat the purpose of the Entity Framework, or am I crazy?
Also, I realize that you can map the insert, update, and delete functionality to stored procedures and this article mentions some interesting ways of implementing that, but creating views for every table would be a major pain. Are there any more practical or easily implemented alternatives?
Best Answer
It depends on ones background and preferences.
Some people came up using stored procedures and are very comfortable with them. They love T-SQL and can do a lot with it. They tend to write the SPs first and then use a minimal wrapper to use the SP. Note some people prefer their SPs a lot of the logic such as validation, business rules, data transformations, etc.
Other people are more comfortable with object oriented programming and prefer to write classes and then serialize those classes to and from a database. In these cases the logic tends to be in the classes.
Entity framework supports both types of development. It is mostly agnostic of development style and not overly opinionated.
But in your situation you and your team need to devise what the standard is. You need to make a decision about how many EF features you are going to use and you style of database development.
I personally lean toward using everything the EF can provide, so I let it generate all of the entities. Then I use Linq to Objects to move data to and from the entities, and let EF deal with the database I/O. I find doing this allows me to create nice tight code that is reusable and testable, and most importantly, understandable.