This project has moved. For the latest updates, please go here.

Structure of Modules

Sep 3, 2011 at 3:54 PM

Hi Jeremy, 

With underlying framework to be our Jounce, what would be your suggestion on the following

1) for a large scale application with CRUD operations how would you construct your modules(structure of your Module xaps which contains Model/View/ViewModel classes to perform CRUD operations using WCF calls) as i couldnt able to see a quickstart that contains a database/xml data retrieval operation performed. 

2) How to reduce the size created due to Service reference for a  WCF services. (when i need only 1 method from a service, it creates proxy for all the methods inside that service. how to avoid that. )

3) Do we really have a project template for CRUD modules that consume WCF services. how do we separate the DTO/Model objects from the proxy classes generated from WCF service reference. 

NOTE:- it would be helpful for everyone if you consider putting a Jounce quick-start that inserts/retrieves data from a data store using WCF services with Jounce as underlying framework. 

Coordinator
Sep 3, 2011 at 4:10 PM

1. I typically start by defining namespaces per module and placing them in folders. A common mistake is to add unnecessary complexity by separating into XAPs before it's really needed. You can start with modules as folders and namespaces and then refactor into separate XAPs when you identify the need.

2. The service client must honor the proxy so if there are a ton of methods that's more an issue of the service definition. Fortunately, the generated stubs are just that - stubs to call, unless you are talking thousands of methods I can't see the non-used methods impacting the size to any level of significance that I'd be concerned with factoring them out. If you control the service, segregate the interfaces better so you have a smaller footprint. If you don't control the service, consider proxying the service from the web tier and exposing a facade.

3. My most common approach is to have a shared set of models, either via a Silverlight DLL (you can reference those from the .NET framework if they are simple models) or linked files (i.e. same models in Silverlight and server, but linked files so one change updates everything) and then in the WCF service client definition, check the box to reuse types so it maps to your model, rather than a generated proxy model.

I agree about the sample quickstart and am working on it. The issue that mentions WCF RIA I think will be best addresesd not by modifying the framework but by showing an example.

Sep 3, 2011 at 5:21 PM

I eagerly await your sample quickstart on WCF RIA to perform CRUD operations. any timescales of when it's likely to be posted. 

It would be helpful if you could share a model of how the project structure will look like, for me to kickstart the Proof of concept about my project structure. 

Thanks for now. 

Again SL Lover!!!!!!