current community

more stack exchange communities

Stack Exchange
tour help
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.
up vote 1 down vote favorite

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

I've got a system that is separated into two applications. An existing VB.NET desktop client using Entity Framework 5 with code first approach and an ASP.NET Web Api client in C# that will be re-factored. It should be possible to deliver OData. The system and the datamodel is still evolving and so migrations will happen in undefined intervals.

I'm struggling how to manage my database access on the web api system. My favoured approach would be use 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 into a separate project and 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 is that it is much more complicated 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 cause more update trouble and out of sync libraries

Database First on Web Api

The second idea was just to use the database first approach an on the 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.

Has anyone ran into similar conflicts or has any advice oon how such a problem can be solved!

share|improve this question
 
Sorry to sound dense but what do you mean by OData? Is it this: odata.org –  Daniel Hollinrake Oct 2 '13 at 13:06
add comment

2 Answers

up vote 2 down vote

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.

share|improve this answer
1  
This is most solid solution. I wonder why the downvotes. –  Euphoric Oct 2 '13 at 14:28
add comment
up vote 2 down vote

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.

share|improve this answer
add comment

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.