How to modularize WCF Services + EF4.1

I am designing a rather big Silverlight-project. I intend to make heavy use of modularity, so I chose MEF and PRISM to help me out there. However, when it comes to data, I'm not quite sure how to tackle the following problem:

Lets say I wan't to make the software available for a shoeshop and a petshop. 90% of the data they need is identical, but the shoeshop needs different columns for its product table than the petshop.

So we need to modularize this part. I can't just make two tables for that, because I want to be able to just write a module for let say开发者_运维技巧 a bookshop later on.

On the EF side, we need a set of classes, e.g. Shoe, ShoeType that belong to the shoeshop-module and a DomainService that exposes those classes. On the client (SL) side, we need a set of Views and ViewModels that represent that data and maybe an implementation of an IProductService interface, that provides access to the context for other modules.

My questions are:

1. How would you design the different DomainServices? One service per module? Do you provide write access to those services for other modules?
2. How do you manage the different datasets? Do you just make a DbContext for every dataset (like for the two entity types Shoe and ShoeType)?

I'm picking that when you say you want a shoeshop and a petshop you're suggesting it could expand beyond just two types as well?

If it's just two or three different types explicitly, I'd go the route of a different service per module. Then explicitly handle the different data sets.

If you could have n number of different store types, you may want to read up on what's called a 'meta model'. This is where you actually model another model type in your database. This way you could have various different products for example but in your database you express that they have different attributes based on the product.

To give a concrete example of this, imagine a content management system. Typically people can define different fields for different page types. For example a 'blog post' has a title, body, author, and a 'generic page' just has body and author. You could either create a table per page type, or you could try and describe a page in the database so when people want to introduce new types they can do so without updating the database schema.

A flow on benefit is that your more generalized model doesn't care about ShoeShop or PetShop, it just knows it gets a Shop and then it works out the attributes based on what's described on the Shop object. Once that is happening, in your scenario, you'd only need one DataService that supports Shop, and one DbContext.

Imagine a model like Shop, has a Fields collection, each field has properties like 'Value', 'Type', etc. It can be a bit of a mind bender and it can be very abstract to deal with so you will want to spike out a prototype to see if you're comfortable -- the challenges could easily outweigh the benefits if you only end up with a couple of store types.

Another concern to be aware of is that building a meta model rich enough to describe everything is a challenge. It's also something that can get the better of some ORMs because they need sophisticated eager load capabilities to ensure you're not getting terrible performance loading in the meta model (I know because we build an ORM for .NET developers called LightSpeed and one of the first things we did was express a meta model with it and tune the eager loading features to ensure we did excellent querying).

I've had a quick Google but haven't found any really easy to follow guides on developing meta model driven applications.

That rounds out my response -- you'll want to do some more reading and other folks may have a better idea but all up it will come down the trade off between flexibility and complexity.

I hope that helps.