Basic Usage of MVVM-Light
- Intialize the DispatcherHelper in the App.cs file’s Application_Startup function
- Create ViewModels from the BaseClass
- Always Create a ViewModelLocator class, which contains all your view models and is Linked in your application Resources
- Use RelayCommands to expose Functions to your view
- Learn when to use the DispatchHelper.
- When appropriate, add to your ViewModel to clear your DomainContext’s EntitySet on Cleanup()?
- Call your ViewModelLocator’s CleanupSomeVM() function to clear viewmodels when they are no longer actively needed in the application.
I would love to hear from others about when/how you use CleanUp functions. As my application grows, I do feel the need to add some cleanup functions to better manage client memory usage.
- Abstract the Service / Query Implementations to an Interface.
- Create 2 classes for each Service Implementation classes (1 for Design, 1 for Production)
- Within your each ViewModel, implement its own Service Class (use IsInDesignMode) to create Blendable Service implementations as necessary.
- Use a Static variable to hold your DomainContext within the Service Implmentation Class.
- Add DispatcherHelper.Initialize() in constructor of ViewModels, but only when in Design Mode. Blend does not load App when loading a page, and this works around that.
For Added Business Logic:
- Add Business Logic in the Model first, then in the ViewModel.
- Use the Model’s partial methods to add logic for appropriate change / update events.
- Add Read-Only properties (only getter) to provide summary and calculated values on your model.
- Always Bind the root to the Locator Object.
- Try to keep code-behind logic to layout or custom UI logic only. Avoid referencing your ViewModel.
- Use CollectionViewSource for collections in your ViewModels, with a source of the DomainContext’s EntitySet
- Apply all Filtering, Sorting, and Grouping Logic to the CollectionViewSource in your ViewModel.
- After ServiceCalls, Call .View.Refresh() on your CollectionViewSource objects as necessary to update the UI.
For ViewModel coordination (Controller Logic)
- Use Messages sparingly, too much complexity can be difficult to manage.
- Use the NotificationMessage and PropertyChangedMessage classes to Send/Receive with.
For RIA DomainServices:
- Implement any logging in the persist changes function, not the update/insert/delete logic.
- During Insert,Update,Delete functions, if you need to reference another Entity via Navigation Property, either check the EntityStatus first, or load the entity from another Context, to prevent EntityStatus conflicts.
For Debugging / Testing:
- Check the Output Window for Binding Errors and Fix them. Binding Errors fail silently to the user, but degrade application performance and expected behavior.
- Create Unit Tests in Silverlight to verify any added Model / Business Logic
- Create Unit Test project to test server-side logic and functions
For Entity Framework:
- Keep 1-to-1 Match of EntitiesContext to Domain Service. Trying to split this another way causes issues.
- Do NOT use the [Composition] attribute unless you fully intend to spend a lot of time carefully building your Insert, Update, and Delete logic.
- Use a separate service to serve custom types back to your RIA Client. Do not add them to your DomainService for your EntityFramework Object
- Perform Server-side update/integration logic (such as updating other systems) in the PersistChangeSet function, not in the Insert, Update, Delete functions. This will prevent you from accidentally pulling in an entity via Navigation Properties, which will leave your detached version non-updated.
- Create an additional Context to find current values during update/integration logic.