Entity Framework Brainmush Kerfuffle Spectacular

Question

I've been wading through all the new EF and WCF stuff in .NET 4 for a major project in its early stages, and I think my brain's now officially turned to sludge. It's the first large-scale development work I've done in .NET since the 1.1 days. As usual everything needs to be done yesterday, so I'm playing catch-up.

This is what I need to hammer together - any sanity checks or guidance would be greatly appreciated. The project itself can be thought of as essentially a posh e-commerce system, with multiple clients, both web and Windows-based, connecting to central servers with live data.

On the server side:

• A WCF service, the implementation using EF to connect to an SQL Server data store (that will probably end up having many hundreds of tables and all the other accoutrements of a complex DB system)
• Underlying classes used for EF and WCF must be extensible both at a property and class (ie field and record) level, for validation, security, high-level auditing and other custom logic

On the client side:

• WCF client
• Underlying classes the same as the server side, but with some of the customisations not present
• When an object is updated on the client, preferably only the modified properties should be sent to the server
• The client-side WCF API details will probably end up being published publicly, so sensitive server-side implementation hints should not be leaked through the API unless absolutely unavoidable - this includes EF attributes in properties and classes

General requirements:

• Network efficiency is important, insofar as we don't want to make it *in*efficient from day one - I can foresee data traffic and server workload increasing exponentially within a few years
• The database gets developed first, so the (POCO, C#) classes generated by EF will be based on it. Somehow they need to be made suitable for both EF and WCF on both client and server side, and have various layers of customisation, but appear as if custom-written for each scenario

Sorry this is so open-ended, but as I said, my brain's completely turned to sludge and I've confused myself to the point where I'm frozen.

Could anyone point me in the general direction of how to build the classes to do all this? Honestly, thanks very, very much.

Answer 1

A few hints in no particular order:

• POCO would be the way to go to avoid dependencies on EF classes in your data objects.
• Consider adding a intermediate layer based on data transfer objects to cope with your "only modified properties" are passed (this requirement will be the tricky part). These DTO will be passed between service and clients to exchange modifications
• Use a stateless communication model (no WCF session) to be able to implement load-balancing and fail-over very easily.
• Share the POCO between client and services, use subclassing on the server to add the internal customized information.

You would end up in the server side with at least:

• A project for the service contracts and the DTO (shared)
• A project for the POCO (shared)
• A project for the WCF service layer
• A project for business logic (call by the WCF layer)

Answer 2

I have few notes to your requirements:

A WCF service, the implementation using EF to connect to an SQL Server data store (that will probably end up having many hundreds of tables and all the other accoutrements of a complex DB system)

Are you going to build only data access layer exposed as set of WCF services or heavy business logic exposed as WCF services? This strongly affect rest of your requirements. If you want to do the former case check WCF Data Services. In the later case check my other notes.

Underlying classes used for EF and WCF must be extensible both at a property and class (ie field and record) level, for validation, security, high-level auditing and other custom logic

Divide your data classes into two sets. Internally your services will use POCO classes implemented as domain objects. Domain objects will be materialized / persisted by EF (you need .NET 4.0) and they will also contain custom logic. If you want to build heavy business layer you should also think about Domain driven design = repositories, aggregate roots, etc.

Underlying classes the same as the server side, but with some of the customisations not present

Second set of data classes will be Data transfers objects which will be exposed by WCF services and shared among server and clients. Your domain objects will be converted to DTOs when sending data to client and DTOs will be converted to domain objects when returning from client.

Your WCF services should be build on the top of business logic - domain objects / domain services. WCF servies should expose chunky interfaces (instead of chatty CRUD interfaces) where DTO transfers data from several domain operations. This will also help you improve performance by reducing number of round trips between client and service.

When an object is updated on the client, preferably only the modified properties should be sent to the server

I think this is achievable only by correct definition of DTOs or perhaps by some custom serialization.

Network efficiency is important, insofar as we don't want to make it *in*efficient from day one - I can foresee data traffic and server workload increasing exponentially within a few years

As already mentioned you have to design your service to be ready for load balancing and you should also think about caching (distributed) - check AppFabric. Good idea is to use stateless services.

The database gets developed first, so the (POCO, C#) classes generated by EF will be based on it.

This seems like simple requirement but you can easily model database which will be hard to use with Entity Framework.

The main advice:

Your project looks big and complex so the first thing you should do is to hire some developers with experience with WCF, EF, etc. Each of these technologies have some pitfalls so it is really big risk to use them in such scale without having experienced people.