Où les méthodes de logique métier vont-elles dans une application en couches utilisant entity framework 6 avec Visual Studio 2015

Question

J'utilise Visual Studio 2015 avec Entity Framework 6 et .NET 4.5.2. Je construis une application WinForms. J'ai structuré mon application en couches comme suit:

Le nom de la solution est TrackingSystem.

projets en vertu de la solution sont les suivants:

• TrackingSystem.UI (en fonction de la couche domaine)
• TrackingSystem.Domain (en fonction du DAL)
• de TrackingSystem.DomainClasses (pas de dépendances)
• de TrackingSystem .DAL (aucune dépendance)

Le projet TrackingSystem.DomainClasses contient plusieurs cla ss définitions qui ont été générées à partir du module complémentaire Entity Framework Power Tools. Ce sont des fichiers de style POCO simples et simples. Juste le nom de classe et les propriétés pour chaque entité de domaine. Exemple:

Public class Location 
{ 
    int locationId {get;set;} 
    string businessName {get;set;} 
    string cityLoc {get;set;} 
    string stateLoc {get;set} 
    string zipCodeLoc {get;set;} 
} 

je référence le projet TrackingSystem.DomainClasses dans mon projet TrackingSystem.UI et l'inclure dans la déclaration des utilisations de ma WinForms zone de code. Je l'ai configuré de cette façon afin que je n'expose pas toutes les classes et méthodes dans ma couche de domaine.

La question que j'ai maintenant est le placement des demandes pour les différentes entités. Par exemple, Disons que je veux ajouter une demande comme suit:

public List<Location> getAllLocations(); 

Je ne veux pas ajouter à la classe d'emplacement dans le projet TrackingSystem.DomainClasses parce que ces cours doivent être simples Poços.

Puisqu'il s'agit de quelque chose que le domaine fournirait après avoir demandé le DAL, je souhaite qu'il soit dans une classe sous le projet TrackingSystem.Domain. C'est là que je ne suis pas sûr de savoir comment procéder. Je pourrais créer une classe sous le projet TrackingSystem.Domain appelé Location, mais j'aurais alors un nom de classe en double dans la solution. Alors peut-être que je pourrais nommer LocationServices où je peux ajouter des demandes liées à l'entité Location. Si je fais cela, je ne suis pas sûr si cela devrait être à la racine du projet TrackingSystem.Domain ou peut-être dans un dossier appelé DomainEntityServices. Où que je le mette, ce serait l'endroit où je créerais des classes similaires pour des demandes liées à d'autres classes (c'est-à-dire ProductServices). J'apprécierais quelques idées ici sur la façon dont d'autres peuvent mettre en place ou s'il y a un document de directives quelque endroit qui aborde comment installer un projet Visual Studio pour des solutions en couches. Merci d'avance. J'ai trouvé un exemple de projet qui montre un cas où le POCO et le code d'implémentation ont été placés dans le projet. Dans ce cas, les POCO et BLL faisaient partie de projets distincts, mais ils conservaient le même nom d'entité. Dans ce cas, un fichier Customer.cs existait dans le projet POCOs et le projet BLL où le projet BLL contenait l'implémentation alors que le projet POCO ne contenait que du contenu POCO.L'exemple de projet est au-dessous URL:

https://code.msdn.microsoft.com/Multilayered-Architecture-703a0d69 

En particulier,

actualisant 20/11/2015 13:36 Je cherche ce qu'il faut faire lorsque le service demandé peut répondre dans le domaine sans demander la DAL telle que la règle de gestion suivante: La ville doit être San Bernardino. Dans ce cas, où dans le domaine dois-je mettre cette vérification de la règle qui ne nécessite pas de vérification avec le DAL? Est-ce que je crée une nouvelle classe comme LocationServices qui aurait la logique de vérifier cette règle et si oui, où la classe serait-elle placée dans un projet Visual Studio en considérant où mes projets sont déjà?

Answer 1

Dans cette situation, j'ai une interface dans le domaine

public interface IAmALocationsRepository 
{ 
    List<Location> getAllLocations(); 
} 

Dans votre domaine utiliser cette interface.

Dans votre DAL de l'implémenter

public class LocationsRepository : IAmALocationsRepository 
{ 
    public List<Location> getAllLocations() 
    { 
    //do things here 
    } 
} 

De cette façon, votre domaine dit qu'il est possible qu'il y ait une liste des endroits que je peux utiliser mais je ne me soucie pas d'où il vient.

Et votre DAL fournit la liste sans que le domaine en soit conscient.