Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I need some help or maybe only a hint for the right direction.

I've got a system that is sperated into two applications. An existing VB.NET desktop client using Entity Framework 5 with code first approach and a asp.net Web Api client in C# that will be refactored right yet. It should be possible to deliver OData. The system and the datamodel is still involving and so migrations will happen in undefined intervalls.

So I'm now struggling how to manage my database access on the web api system. So my favourd approch would be us Entity Framework on both systems but I'm running into trouble while creating new migrations. Two solutions I've thought about:

Shared Data Access dll

The first idea was to separate the data access layer to a seperate project an reference from each of the systems. The context would be the same as long as the dll is up to date in each system. This way both soulutions would be able to make a migration. The main problem ist that it is much more complicate to update a web api system than it is with the client Click Once Update Solution and not every migration is important for the web api. This would couse more update trouble and out of sync libraries

Database First on Web Api

The second idea was just to use the database first approch an on web api side. But it seems that all annotations will be lost by each model update.

Other solutions with stored procedures have been discarded because of missing OData support and maintainability.

Does anyone run into same conflicts or has any advices how such a problem can be solved!

share|improve this question

migrated from stackoverflow.com Oct 21 '13 at 18:41

This question came from our site for professional and enthusiast programmers.

This question appears to be off-topic because it is about high-level architecture and design. This question may find a better audience at Programmers.StackExchange.com, where they help with the sort of problems you'd solve with a whiteboard, rather than a debugger. –  Tragedian Oct 2 '13 at 10:51
@Tragedian: Thanks for this advice I didn't know about programmers.StackExchange.com –  Dirk Beckmann Oct 2 '13 at 11:11
The main problem ist that it is much more complicate to update a web api system than it is with the client Click Once Update Solution How do you figure? Your database project will compile down to a dll and you put that dll in the same place as your web dll –  Shoe Oct 21 '13 at 19:08

2 Answers 2

Best to go for the shared DLL strategy. You can manage the Web API updates through use of a versioning strategy for the API to ensure backward compatibility with the clients.

share|improve this answer

So I think you pretty much called this out on your own. You're going to have duplicated code if each side has it's own EF mappings. This doesn't buy you much at all and puts you at risk for becoming out of date. While creating a shared assembly that houses all the EF mappings/code would allow you manage everything in one place. The fact you're using EF here is kinda of immaterial. This is the perfect example of a shared assembly between projects. This is a common pattern.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.