Domain Logic in Service Layer - comment le référencer et l'exposer

Question

Je conçois une solution d'entreprise qui consiste en des produits modulaires dans une gamme de produits en utilisant le code Entity Framework pour définir le modèle de domaine et fournir l'accès aux données.

par exemple. Solutions:

ProductRange.Authentication 
ProductRange.Gateway 
ProductRange.OrderSystem 
ProductRange.MarketingSystem 

Chacun de ces produits (solutions) auront des couches similaires, actuellement:

projets dans chaque solution:

ProductRange.OrderSystem.Model (contains code first POCOs) 
ProductRange.OrderSystem.DataContext (contains the dbContext) 
ProductRange.OrderSystem.DataAccess (contains the Generic Repository) 
ProductRange.OrderSystem.Service.DomainLogic (contains business logic) 
ProductRange.OrderSystem.Service.ApplicationLogic (contains application logic) 
ProductRange.OrderSystem.Presentation.AdminWebsite 
ProductRange.OrderSystem.Presentation.CustomerWebsite 

Certains des produits devront accéder à la logique de domaine d'un autre produit, en particulier ils auront tous besoin d'accéder à la ProductRange.Authentication, mais aussi ProductRange.MarketingSystem devra interroger ProductRange.OrderSystem

Je pense à exposer la logique du domaine entre les produits de la gamme via un service WCF. Mais je devrai également référencer le produit localement (par exemple créer des références de projet).

Comment dois-je procéder pour implémenter ceci? Devrais-je créer un service WCF, par ex. ProductRange.OrderSystem.WCF qui appelle la logique du domaine et l'expose ou est-ce que la logique de mon domaine doit être elle-même un service WCF? Dans ce dernier cas, devrais-je toujours faire référence à ma logique de domaine via le WCF, même à partir du logiciel ApplicationLogic local? Je suppose que je suis à la recherche de conseils sur les couches à avoir et la meilleure façon d'assurer l'inter connectivité entre les solutions.

Answer 1

Vous pouvez utiliser une seule couche (ou plusieurs couches) pour exposer vos objets en tant que contrats de données et contrats de service.

par exemple:

ProductRange.Server.DataContracts 
    Product 
    AuthenticationInfo 

ProductRange.Server.ServiceContracts 
    IOrderService 
    IAuthentication 
    Auth(AuthenticationInfo info):AuthenticationResult 

ProductRange.Server.Services 
OrderService 
AuthenticationService(implements IAuthentication interface) 

Du côté client, vous pouvez consulter ce projet (seuls contrats de données et de services) et de créer proxy transparent sur des interfaces telles que:

var serviceProxy = SomeHelper.CreateServiceProxy<IAuthenticationService>(); 
var result = serviceProxy.Auth(new AuthenticationInfo()); 

En plus: vous pouvez utiliser vos classes poco comme un contrat de données. Si vous voulez une meilleure connectivité, vous choisissez une liaison (comme un net.tcp) pour vos besoins.