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!
4
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.
1
The problem is that even though you’re using EF to remove the burden of shuttling data to/from the DB from the rest of your code, your clients are still too dependent on the database schema. Thus changes to the schema impact the clients.
Ideally, you would have an application service layer that exposes a consistent API for the clients, this should be a relatively stable interface. It should expose a simplified version of the Domain Model that might hide some of the details of the Model’s relationships for the client.
This gives you room to allow for changes and modifications to the database/domain model without necessarily impacting the clients. Behind the interface, the service layer is responsible to mapping inbound requests to operations on the Domain Layer and for transforming objects from the domain layer into objects that the client can understand.
As a rule of thumb, I do not expose Domain Objects directly to the client. This liberates the domain to change as necessary to support the business.
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.
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.