实体框架模型可重用吗？

Question

How reusable are the results of using EF ?

Currently, I use stored procedures for 100% of my data access. The main reason I may be looking to do things differently for my newest project is for maintainability: adding an attribute to a table means manually altering dozens of stored procedures. If I understand EF correctly, I should be able to add an attribute to an Entity in my EF model, and then ask EF to update my CRUD methods for me. awesome.

However, there is one thing holding me back: reusability. I like that I can make the SP's for a given database once, and be done with them; I can make 12 applications that all use that database and getting that data will be as easy as calling the correct SP.

• Will the same be true if I switch to a more EF-centric approach?

• Can I import an Existing EF Data Model and have it work without too much trouble?

• Can I make it so that I alter the Data Model once, and that change is felt across all applications?

Answer 1

Ad1. You can easily reuse complex EF queries if you follow the Repository pattern. Repositories are where you encapsulate your data access and, yes, repositories are easily reused between different modules/applications.

(not that you can't reuse code without Repositories! Repositories are just a common way of doing it for data access layer)

Ad2. I am not sure what you mean by "import existing EF model" (import where?) but usually EF models are straightforward and can be reused

Ad3. Just have your model in a separate assembly.

Answer 2

A real benefit to using EF is getting away from stored procedures. The problem that exists with using stored procedures for all your data access is that you are forced to put business logic into your data layer .

Check out Should the data access layer contain business logic? While its not true in every case, generally keeping your business logic in your business layer gives you better separation of concerns.

I have an EF project that I use as the data layer for several applications. This allows me to change it once and have all the other projects get the benefits. Granted, sometimes supporting code needs to be changed in these other projects, but you'd have that same problem in a stored procedure model as well.

Answer 3

Any N-tier design would solve this problem by simply creating a class (in a class library) that understands how to access the data by using entity framework. Then any applications that want to access the data uses the class library, configure a connection string in the app.config or web.config and you're done.