Question de conception pilotée par domaine sur les services et les dépôts

Question

J'ai deux entités User et Course. Un utilisateur peut suivre plusieurs cours, ce qui rend la relation un à plusieurs. Mais un seul cours peut être pris par de nombreux étudiants, ce qui en fait de nombreuses relations.

Maintenant, je dois enregistrer un cours pour un utilisateur. Mon entité utilisateur a:

public void AddCourse(Course course) 
     { 
      if (CoursesAlreadyAdded(course)) 
      { 
       AddBrokenRule(new BrokenRule() { PropertyName = course.ClassCode, Message = String.Format("Course with classCode = {0} already added", course.ClassCode) }); 
       return; 
      } 

      UserCourses.Add(new UserCourse() { UserId = this.UserId, CourseId = course.CourseId, Course= course, User = this}); 
     } 

Les classes sont générées via Linq to SQL. Linq to sql n'est pas capable d'effectuer plusieurs à plusieurs relations donc je dois le gérer moi-même.

Maintenant, la question est de savoir comment vais-je envoyer les informations à la base de données. Should UserRepository.Save (utilisateur) devrait être responsable de l'enregistrement des cours. Cela signifie que l'utilisateur est la racine agrégée de l'entité du cours mais en réalité ce n'est pas parce que je peux accéder au cours de nombreuses façons différentes et je ne suis pas dépendant de l'objet Utilisateur pour me fournir un cours.

Même si j'ai un CourseRegistrationService (que j'ai), je dois appeler un référentiel pour conserver les changements. Le référentiel est responsable de la persistance des modifications sur les relations utilisateur et cours. Peut-être un UserCourseRepository !! De plus, en plaçant un objet List sous User, l'utilisateur devient une racine agrégée ou est incorrecte. Si c'est le cas, comment concevez-vous l'application en utilisant OR MAPPERS qui génère List et une à plusieurs relations automatiquement.

Answer 1

En termes de DDD, vous devriez penser aux agrégats et aux racines agrégées. Est-ce qu'un utilisateur "possède" le cours? Probablement pas.

Au lieu de cela, en pensant comme cela pourrait vous donner une meilleure conception:

utilisateur a beaucoup d'inscriptions. L'inscription est associée à 1 cours.

Maintenant vous n'en avez plus autant. Vous avez un objet de première classe que l'entité User "possède".

L'enregistrement serait un objet de valeur (avec ID utilisateur, ID de cours et éventuellement DateAdded).

En ce qui concerne l'utilisation de méthodes pour ajouter aux deux côtés d'une collection, c'est quelque chose que je fais aussi bien avec NHibernate.

Answer 2

J'ai rencontré une solution similaire, mais j'ai utilisé une approche complètement différente. J'ai ajouté du code à mes classes LINQ to SQL pour qu'elles prennent correctement en charge les relations Many-to-Many. Consultez ce blog pour les derniers détails:

Mitsu's blog: How to implement a many-to-many relationship using LINQ to SQL

Pour ce qui référentiel doit gérer l'ajout d'un étudiant à un cours classe , le nom de votre service devrait vous donner un indice (CourseRegistrationService). Le référentiel de cours devrait ajouter des étudiants à une classe.