Modules Organization

Nov 7, 2011 at 10:15 AM

Hello again,

please excuse me if I post question here and maybe the most part of you are just well known about how do things but for me it's new and I don't want to start in a way and discover after sometime I got totally wrong...

In the demo I've got a SL project and a Web (containing the edmx) and everything is fine... moving to a modular sample what should I do? I've created a solution folder called Modules where I put my first module called ModuleSearch (its' a SL project with the references to IdeaBlade and CaliburnMicro) ,what should I do for the edmx of the module? In my tougth it would be best to have a complementar one so that if I need to deploy a new version I substituite the dll and not have to deploy again a full version of the web service, is it possible ? should I only use one edmx for the whole application?




Nov 7, 2011 at 5:29 PM

We recommend to break your domain model down to smaller edmxs, one for each major area/functional area/module of your application. That way you can optimizie the model for what it's being used and they stay at a manageble size. The appropriate granularity depends on your application. You don't want to go too fine grained and end up having to manage a ton of models. Each model should be put in it's own assembly. In case of SL, a pair of assemblies. We don't usually add classes etc. directly to the web project, instead we add references to all the various assemblies that contain all the server side pieces. You gain tremendous deployment flexiblilty, especially if you get into breaking your application up into multple XAP files.

I don't have an example with multiple models in the source code, but if you look at CoProjectDF, HelloWorld and SampleApplication, you'll notice that in all three cases, the model (edmx) is in a seperate assembly. In a multiple model application you just have more of them.

Nov 8, 2011 at 6:51 AM

Hello marcelgood,

thanks for your reply.... ok so if I've understood well if I've got ModuleA I'll Have ModuleA.SL (with the View/ViewModels) and Web.ModuleA where it contains the edmx, custom class and so on, in whe Web I add a reference to Web.ModuleA ? With a "In case of SL, a pair of assemblies" what do you mean max 2? I would have one module for order, one for customers and so on.... where should I put the definition of IShell , Bootstrapper and so on if they need to be shared across the projects? in a SL.DO ? last question (I promise!) the module projects are Silverlight/WPF Class Library projects?


Nov 8, 2011 at 5:33 PM

Let me explain this in a different way, before you start heading down the wrong path. Forget about modules and take a look at your domain model. A typical domain model is made up of several subdomains and again forget about application modules. When it comes to application modules, there isn't necessarly a 1-to-1 relationship between a subdomain and a module. It's very common that several modules use the same subdomain or a module may even use multiple subdomains.

For example, a subdomain could be Finance. Then two possible application modules would be Accounts Receivable (AR) and Accounts Payable (AP). Those are typically two distinct modules in any Finance software, but they both would use the Finance domain model. Makes sense?

So having said that, for each subdomain you will create two assemblies if you are developing in Silverlight. If you are developing in WPF, than you could get by with one, although things like the repository would only be used on the client, so one might want to create two assemblies as well, but let's look at how it would be broken up for a Silverlight app.

SubDomainA.SL.dll: (contains: linked SubDomainA.IB.Designer.cs (the code generated by DF), any linked partial entity classes, Repository (1 per subdomain is usually enough), EntityManagerProvider and optional SampleDataProviders and any other model helper class, such as projection classes)

SubDomainA.Desktop.dll (contains edmx and SubDomainA.IB.Designer.cs, any partial entity classes and projection classes, essentially any types that will be involved in queries and therefore need to be known on the server)

SubDomainA.SL.dll will be a Silverlight Class Library and SubDomainA.Desktop.dll will be a Windows Class Library.

Once you have that, then you can move on to the application modules and create a Class Library for each module that contains the Views and ViewModels and any other classes you need, and then bring it all together in a Shell (Silverlight or WPF Application) that can launch the individual modules.

Hope that sheds more light on it. We are getting into Application Architecture Consulting, which is something our Professional Services arm does. So if you need help putting things together, consider contacting us.

Nov 8, 2011 at 8:21 PM

Quick follow up, because this might be a question in your head at one point. One often misunderstood capability of the EntityManager is that any EntityManager can query multiple domain models. When you create an edmx, DevForce generates an EntityManager for that model. It's often mistakenly assumed that one has to use this and only this EntityManager to query that edmx. In fact, these generated EntityManagers are for convenience only. If you look at them, all they have are base query properties for each of the entities found in the edmx, so it's convenient to use them. But you can query any entity from any model with any EntityManager by simply calling the GetQuery<T>() method of the EntityManager to get the base query to retrieve entities of the specified type. Doesn't matter which edmx the type comes from.

With this said, application modules that need to combine data from multiple subdomains can use a repository that uses a single EntityManager to combine the data from multiple models. Even further, each of the edmx could connect to a different physical database. If you then modify the entities in the cache and do a save, DevForce automaticially starts a distributed transaction if necessary to save the changes back to the respective databases and all in one transaction.

So, this goes further to say that there is never a forced relationship between an edmx and a module in your application. You break up your domain model in subdomains that make sense and then use them as you see fit in the various modules.


Nov 9, 2011 at 3:38 PM
Edited Nov 9, 2011 at 3:40 PM

Hello Marcelgood,

Ok I've got it... now I start developing some sample application

Thanks again


P.S. In a WPF project, it's best to have again a SubDomainA.WPF adn a SubDomain.Desktop (in a future prospective to create a SL Module) or not?