Entity framework/WCF -- Safe/smart to send entityObjects to Silverlight client?

Question

I'm a little confused here.

I have my POCO classes created with the entity framework modeled from the datbase.

Obviously, I'd like to use these classes in the client too (and any bookkeeping on them would be nice if I'd like to send them back and re-attach)

I looked through the classes generated for the WCF service reference and it seems a bit verbose to be sending over the internet, but it doesn't look like there's anything risky in there security-wise.

And yet, I can't find anything online about doing this. Am I going down a completely awful path?

Help?

EDIT : I suppose they're technically they're not POCO classes if i had them generated by the EntityFramework from the database; just to clear up any possible confusion.

Answer 1

This is a difficult question to answer without knowing more details about your system, but ultimately whether exposing your EF entities in the WCF service contract is the right path or not is influenced by the scope and requirements of the application you are developing.

Perhaps ask yourself the following questions which will hopefully guide your decision:

1. Is it likely your relational model and object model will need to diverge? This can be driven by a number of factors, but most commonly reporting requirements may enforce a certain design on your database schema (for performance) that you do not want to reflect in your application object model. Using the DB generated EF entities throughout the application layers can bind you to this database design
2. Are you concerned that changes to your database schema may require your clients to regenerate their service references? Again, using the EF entities throughout your application tiers means any changes implemented in your DB schema (whether of concern to the client or not) may bubble up to the service interface, potentially breaking client compatability with that interface
3. Is performance a concern? As you mentioned, the generated classes are verbose. You are likely to be transporting unnecessary baggage across the wire, which could be optimized.
4. Are you concerned about exposing the implementation details of your database schema and persistence mechanism on the wire and to your clients? Given you have generated the model from the database there are likely to be properties that expose information about your schema and persistence mechanism that are redundant from a client's perspective.

In summary there may be a limited number of cases where exposing the EF entities may be acceptable but typically I would design for change and implement some sort of pattern where you map your EF entities to light-weight "persistence-ignorant" POCOs at your repository layer. EF 4.0 does provide the ability to code up a context that returns POCOs, but on my current project we use the codegen'd context and then use automapper to map the EF entities to our data contracts. Outside of the repository layer nothing is aware of the EF entities and I feel this allows for a more maintainable and robust design.