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!
Best Answer
Assuming you are using a single database for both, I would look at having the database and ORM layer behind a web service that both UIs can consume. That would allow you to put your business logic where it needs to be and decouple things so that the day you need a mobile interface or whatever else, you don't have to write another data access layer. Assuming you are using WCF on a windows stack, some of the native bindings should be as fast as you need them to be and designing for this environment forces some good habits in terms of data management.
Having the facility to put some logic on the service side also saves on having to write anything twice.
The downside is that updating your API affects all your clients, so you might want to have that well defined to start with and it does mean your desktop client and your web api client are tied in more closely to the application as a whole, but given that they are sharing a data store to start with, that is not necessarily a bad thing.