Multiple design surfaces

Hi,

Is it possible to have many design surfaces for the same domain model (so I can design each part of the model in a separate designer)?

Also what is the recommended way to split system into components? For example, I need to have set of domain models: Security, Payments, Customers etc in separate assemblies.
But the actual application can use Security & Payments, or only Customers or any combination of those.

Cheers,
Dmitriy.

Hi Dmitriy,

No, it is not possible to have multiple design surfaces for the same domain model.  We're aware that people are keen to get this but it's difficult for us to do in the current version of Visual Studio.  (We've been told that improvements are coming in VS2010, but we haven't had the chance to get our teeth into this yet.)

In the meantime, we do offer the ability to filter the view, which can be used to implement these kinds of sub-views.  See http://www.mindscape.co.nz/blog/index.php/2009/05/26/sub-views-in-the-lightspeed-designer/ for more information (you will need a recent nightly build for this).

Splitting the domain into different models (whether in separate assemblies or the same assembly) will Just Work provided that (a) you do not need associations across models (e.g. from something in the Payments model to something in the Customers model) and (b) you do not need to use LINQ.  Actually, the LightSpeed runtime will handle (a), but there's no way to express it in the designer.  So you can fix this somewhat by declaring the associations in partial classes.  But in this case you would need the models to be in the same assembly because you have to declare both ends of the association which would otherwise result in a circular reference.  You can also work around (b) by writing your own LINQ unit of work class patterned after the ones in the designer (but in a multi-assembly scenario this will involve either taking dependencies or writing per-consumer-assembly combined UOWs), or by writing explicit IUnitOfWork.Query calls instead of using wrapper properties.

To be honest, my recommendation would be to build a single model and use tagging and filtering if possible, or to build multiple models in a single assembly if not.  Could you say a bit more about why you need the different components to be in different assemblies?

Hi,

Thanks for the quick reply. 

[quote user="ivan"]Could you say a bit more about why you need the different components to be in different assemblies?
[/quote]

A lot of applications share the same models with little additions, so instead of remodeling everything from scratch we want to reuse particular component.

That's pretty much it. Reusing instead of redeveloping.

Cheers.

Hmm, this isn't as elegant as reusing the binary components, but have you considered adding .lsmodel files as links?  That way you could combine multiple .lsmodel files into the same assembly, but still be able to reuse those same .lsmodel files in other assemblies.

E.g. you create Security.lsmodel, Payments.lsmodel and Customers.lsmodel.  In the project for a payments library, you add Security.lsmodel and Payments.lsmodel as links.  In the CRM library, you add Payments.lsmodel and Customers.lsmodel as links.  Payments.lsmodel is now reused across the payments and CRM libraries, though it is built separately into each library.

I realise this depends on programmers remembering to Add Existing > Link to File rather than just Add Existing, and that it may create versioning issues (oh, and we've not tested this scenario!), but possibly worth considering.

Hi Ivan,

This might work but I'm not too sure about this scenario.

Anyway, thanks for the info.

Cheers.