0

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?

crthompson
  • 15,653
  • 6
  • 58
  • 80
JHixson
  • 1,512
  • 2
  • 14
  • 29

3 Answers3

3

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.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
  • Bullet 2 just asks the same question as bullet 1, just worded differently. I mean import in the sense of creating some sort of DAL library or, as you put it, repository, that can be added to multiple projects. I'll look into the Repository pattern. – JHixson Sep 16 '13 at 20:05
  • Then follow Bullet 3 - just have your model in a separate assembly you reference from all your apps. – Wiktor Zychla Sep 16 '13 at 20:09
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.

Community
  • 1
  • 1
crthompson
  • 15,653
  • 6
  • 58
  • 80
  • Right, maybe I wasn't clear, but this was exactly my goal. I find SP to be a nightmare to maintain, and I am looking at using EF as my alternative. I just wasn't sure If EF had to be tightly coupled to the application, or if it could exist in it's own assembly and added as needed. – JHixson Sep 16 '13 at 21:34
  • Absolutely! `EF` will give you all that flexibility and more. I like keeping the project handy, but compiling it to an assembly and referencing it, allows you to regulate who edits the `EDMX` as well. @Wictor's repository pattern is a great suggestion too. Best of luck! – crthompson Sep 16 '13 at 21:42
0

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.

Erik Philips
  • 53,428
  • 11
  • 128
  • 150