WPF WCF Prism and MVVM - the right way to expose objects

Question

We will be developing a large enterprise desktop application very soon, and I spent some time exploring the WPF + PRISM + MVVM approach, I have a good understanding of most of the concepts, and I love the modularity that it provides.

In case of problems, the question arises of how to archive the service layer for data input and output, especially when this service is introduced by the module with the idea that the dependent module can use it.

I wanted to divert my WCF data services from within application services and use ServiceLocator to resolve specific instances from my view models, however, it’s hard for them to find how this should hang together, mainly because of my authority as part of the WCF service.

for example

Module1 Contains WCF service + Specific application service (ISearchService) + generated WCF service objects (model)

Module1.Infast structure . Contains the following interface for application services.

 public interface ISearchService { ObservableCollection<Person> Search(string search); } 

this will be registered with UnityContainer so that any other module can get the specific implementation imposed by the module.

My problem is that Entities ( Person ) are defined in the module itself (in the WCF service), therefore, presenting the service and then expecting that any other modules will be able to use it, they should refer to the module by itself, not only the module infrastructure, if I do not pull the services to another assembly.

Should I expose my rights that are automatically generated from my EF model in this way?

Does anyone have a better solution?

Answer 1

That's how it is.

I am currently using Silverlight + PRISM + MVVM + WCF (RIA) services.

In the current project architecture

• Application.Domain: contains all the first EF codes, including metadata and business validation. Does not include database generation.

• Application.RIAServices: This is a project that contains automatically generated classes from the WCF RIA Services web project. I can link to this project in both WPF and Silverlight.

• Application.RIAServices.Web: A web project containing DomainServices code and database generation code using DbContext. this is a WCF RIA reference project for Application.RIAServices

• Application.Infrastructure: Here begins. Because, like you, I have a Person / Customer Service using the ICustomerService interface. Since I want to use this service, for example, in an application, and not just in ModuleA, I put this interface in the infrastructure. All projects contain a link to this project.

• Application.Modules.ModuleA -> Application.Modules.ModuleD: General modules providing functionality. All of my modules (which use WCF RIA services) have a link to Application.Infrastructure and Application.RIAServices projects.

• Application.Shell: launch project. with the bootloader and registration of all relevant modules.

Reading the question Rachel made me think about some things, and I just wanted to leave my structure on how I did it. Perhaps you have an idea about this. I don’t want to go to DTO, although things like validation integrate so well into WCF RIA services that they automatically appear in the text box when something is wrong and an error message is displayed. We look forward to your opinion and the outcome of the question / question

Edit:

Application.Domain also has a separate structure.

I have my models. Only container properties that need to be mapped to the database. Then I have a folder with metadata. Now for this I need to have the same namespace as my Entity, and I am making the entity an entity. I create an Entity.metadata.cs file and there I create an internal sealed class EntityMetaData , copying the properties and adding attributes to them. Using the MetadataType attribute above the Entity class, it adds all of these attributes to the EF / WCF RIA code generator.

One of these attributes is CustomValidation It uses the static class and paramater parameter and checks the entity on the server. Or if you create a file with the extension .shared.cs, it will be generated in the Application.RIAServices project.

Possibility

To try to answer your question, you can have only 1 option, and this is what you suggested at the beginning. You can create a Customer.Infrastructure project.

this project contains an interface for ICustomerService, Entity / DTO / POCO, whatever you want, and possibly even an implementation of this ICustomerService or WCF service. This allows all your modules to reference this project and thereby not create dependencies between the modules.

Answer 2

You can define the IPerson interface, implement its object (using partial classes) and use it in your contract. Another option, if you prefer, is to split the entity definitions into your own assembly or simply include them in the contract assembly.