Migrate from DataSets to EntityFramework

Question

I'm currently looking into possible ways we can refactor our codebase, to make it easier to work with.

The application is fairly large Asp.Net Webforms app, with all data setting / retrieval happening through Web Services. Currently, these WebServices return DataSets, containing 1 or more tables returned from Stored Procedures. The codebase is quite tightly connected, with the ASP code-behind calling the WebServices in multiple places, and most of the business logic happening either in the code-behind or in the Stored Procedures.

For a while now, we have been looking at possible ways to update the application, and modernize the code-base. We can't (and don't want to) re-write the whole app, but it would be great if we could start moving it, bit by bit, towards a newer architecture. I have looked into the MVP architecture, which seems like it would be a nice match to our current architecture - it won't involve too much re-writing, but should still result in more testable code (another goal - we currently have no automated testing).

I'd like to know, though, if any one has some tips / information / articles on moving from DataSets to EntityFramework. I feel that this would result in the biggest advantage for us, since it would allow us to model our data and test it much easier. Unfortunately, I haven't yet been able to find anything online regarding this kind of migration. Our database design is pretty good (thankfully), but we would have to work with both DataSets and EntityFramework for a while until we got rid of DataSets - there's no way we could do it all at once.

Any one able to give advice on this?

Answer 1

It sounds like you need to solve two separate problems.

1. How do you make use of EntityFramework inside the web service(s).
2. Second, how do you pass those results to and from the web services.

For #1, we can only guess about relevant details of your current implementation. However, it is likely a common change that you could search and find help for.

For #2, you probably want to define a series of business objects that go back and forth. The web service could translate between them and the EntityFramework objects. (You could presumably pass the EF objects directly, but there could be issues there depending upon your scenario.)