Entité, Objet de valeur ou représentation enum des objets dans le modèle de domaine

Question

J'essaie de construire un système de gestion de documents et malgré tous les thèmes que j'ai lus sur les entités, les objets de valeur, comment choisir entre les cartographier etc. .. Je ne peux toujours pas comprendre ce que la "bonne" façon de le faire est. Tout à fait généralement dans un tel scenerio, chaque document peut Beong appartiennent à une ou plusieurs catégories, peuvent être consultés par les utilisateurs appartenant à un ou plusieurs rôles, etc ... Ainsi, l'entité document ressemble à ceci:

public class Document 
{ 
    private int _id; 
    private string _title; 
    private string _brief; 
    private DateTime _publicationDate; 
    private string _author; 
    private string _source; 
    private DateTime _activeDate; 
    private DateTime _inactiveDate; 
    private IList<Category> _categories; 
    private IList<Fund> _funds; 
    private IList<Role> _roles; 
    ...etc 
} 

Le Le domaine actuel mondel et la logique métier de l'application sont actuellement assez fins, donc les objets Catégorie, Fonds et Rôle ne contiennent aucune logique métier et ne sont en réalité que des moyens de catégorisation, de contrôle d'accès etc (dans le cas des Rôles) etc ... la base de données par conséquent, j'aurai des tables 'Role', 'Category', 'Fund' par exemple et puis il y aura des tables de mappings many-to-many avec 2 colonnes: eg DocumentId et RoleId. Ma question est donc:

Devrait-on représenter la catégorie, le fonds, le rôle etc. dans le domaine en tant qu'entités, par ex.

public class Role 
{ 
    private int _id; 
    private string _name; 

    public virtual int Id 
    { 
     get { return _id; } 
     private set { _id = value; } 
    } 

    public virtual string Name 
    { 
     get { return _name; } 
     private set { _name = value; } 
    } 
} 

ou comme des objets de valeur ou si les rôles par exemple être juste un ENUM:

public enum Role 
{ 
    AllUsers 
    ,ShareHhlders 
    ,Registered 
    ,Administrator 
} 

J'ai commencé avec les entités approche, mais maintenant je suis en train de créer la fonctionnalité « Ajouter document » et l'interface utilisateur et la question de savoir si c'est la bonne approche - Dans l'interface utilisateur du document d'ajout, l'utilisateur obtient des groupes de listes de cases à cocher et sélectionne les catégories, les fonds de fonds, etc. auxquels le document appartiendra. Si cette information est transmise au contrôleur (j'utilise ASP.NET MVC) si une case à cocher a été cochée, alors une catégorie/un rôle/un fonds, etc ... doit être créé et ajouté à l'objet document, mais pour ce faire, Id de la catégorie/rôle/fonds est nécessaire. Cela signifie donc que je dois éventuellement gérer des objets de mappage dans l'application pour que les identifiants de catégorie/rôle/fonds d'une catégorie/d'un fonds/d'un fonds donné passent aux constructeurs des objets catégorie/rôle/fonds. Cela ne semble vraiment pas juste et par conséquent pourquoi je pose la question.

J'ai commencé à essayer de remplacer les objets par des énumérations, mais les tableaux d'énumération et de catégorie/rôle/fonds/mappage plusieurs-à-plusieurs utilisés pour l'intégrité référentielle devront être conservés séparément. Cela peut sembler être une exigence pour satisfaire la persistance mais au niveau de la base de données, je pense qu'il est nécessaire de maintenir des tables de catégories/rôles/fonds séparées, des tables de mappage et des contraintes de clés étrangères. (En utilisant également NHibernate pour le mappage ORM et la persistance, ut devrait être capable de le rendre agréable avec les énumérations).

Merci

Answer 1

Lors du choix entre les entités et les objets de valeur, il est important de déterminer si l'objet a une identité unique avec des pièces internes qui peuvent être modifiés. Si l'objet a une identité unique et prend en charge les modifications internes, ces modifications doivent-elles être suivies ou conservées dans la base de données? En bref, avez-vous besoin de poursuivre les opérations CRUD sur ces objets? Si oui, vous pouvez avoir une entité. Sinon, vous pouvez avoir un objet de valeur. Mon instinct dit que si vous pouviez créer des énumérations à la place des entités, vous n'avez pas besoin d'objets d'entité. Je vote pour utiliser NHibernate pour enregistrer les clés étrangères pour l'intégrité référentielle.