I've been working with the alpha version of Entity Framework 6 (EF6) for a short time now. I'm using EF6 in a real-world project currently under development. I don't make it a habit of using pre-release software for projects like this. However, the ability to map modifications (insert, update, and delete) to stored procedures is just what I need. I wanted to use an ORM solution and I've used and liked EF for other projects since POCO support became more well-rounded.
I want to point out the shortcomings in the current implementation that I find frustrating. I understand that this is an alpha release; however, I haven't received any indication that there will be any changes. Hopefully, knowing these issues will save you some time. Here are my big four:
- All three stored procedures are required -- My problem domain has certain considerations that mean some entities don't require deleting and sometimes updating. The current implementation of stored procedures in EF6 require you to define all three.
- Stored procedures require parameters for all properties -- This applies to insert and update stored procedures. There are some things that just don't need to be updated; for example, I have properties that will always be the same at creation (enforced by the table definition) and properties that once set cannot be changed. You can ignore parameters within your stored procedures. But, that's not good practice and is just sloppy. I cannot bare to do this, so I'm enforcing restrictions at the code portion of the data layer.
- Stored procedures for deletions require parameters for foreign keys -- I don't know why (a question on the EF forums went unanswered) that you need to specify parameters for foreign keys on delete stored procedures. For example, if you have a table Order(OrderId, CustomerId, ...) then you'll have to specify a parameter for CustomerId. Odd. However, it's worth noting this only occurs if you choose to not clutter your entities with specific foreign key properties.
- Fluent API is required if you deviate from convention -- There is no declarative way to provide a stored procedure name, or names for parameters. I don't like the conventions including "TableName_Insert". This means if you want a different naming scheme or put your stored procedures in a schema other than dbo then you're forced to override a method on the DbContext and call into a method for each entity type.
There's no point of rehashing the procedures for using stored procedures with entities. The documentation topic on the CodePlex site covers the basics well enough.