Je suis généralement d'accord avec Mosh sur celui-ci. Cependant, gardez à l'esprit la notion de transactions dans le point de vue des entreprises. J'ai donc fait prendre "aux fins de la modification des données" pour dire "dans le but de la transaction(s)".
Les référentiels sont des vues de modèle de domaine. Dans un environnement de domaine, ces "points de vue" vraiment de soutien ou de représenter une fonction commerciale ou de la capacité d'une transaction. Affaire au point, l'Employé peut avoir une ou plusieurs violations, et si oui, sont des aspects d'une transaction(s) en un point dans le temps. Examiner votre cas d'utilisation.
Scénario: "Un employé a commis un acte qui constitue une violation du milieu de travail." C'est un type d'événement d'entreprise (c'est à dire de la transaction, ou une partie d'un plus grand, peut-être distributed transaction) qui a eu lieu. La racine de domaine affecté objet peut être vu à partir de plus d'un point de vue, c'est pourquoi il est source de confusion. Mais la chose à retenir est que le comportement se rapporte à une transaction commerciale, puisque vous voulez que vos processus d'affaires afin de modéliser le monde réel aussi précises que possible. En termes de relations, tout comme dans une base de données relationnelle, votre conceptuel du modèle de domaine doit indiquer ce déjà (c'est à dire l'associativité), qui, souvent, peut être lu dans les deux sens:
Employé-e <----commet un -------commis par des ----> la Violation
Donc, pour ce cas d'utilisation, il serait juste de dire que c'est une opération de traitement des infractions, et que la racine ou la "première" de l'entité est une Violation. Qui, alors, serait votre racine d'agrégat vous de référence pour l'activité de l'entreprise ou de processus d'affaires. Mais ce n'est pas à dire que, pour une autre activité ou d'un processus, que vous ne pouvez pas avoir un Employé d'agrégation de la racine, comme le "nouvel employé processus". Si vous en prenez soin, il devrait y avoir aucun impact négatif du cycle des références, ou d'être en mesure de traverser votre modèle de domaine multiples façons. Je vais avertir, cependant, que les gouverneurs de ce qui devrait être pensé et géré par votre contrôleur de pièce de votre domaine d'affaires, ou que ce soit équivalent vous avez.
De côté: Réfléchir en termes de modèles (c'est à dire MVC), le référentiel est un point de vue, les objets du domaine sont le modèle, et donc on doit également employer une certaine forme de modèle de contrôleur. Généralement, le contrôleur déclare la mise en œuvre concrète et l'accès aux référentiels (les collections de l'ensemble des racines).
Dans l'accès aux données du monde...
À l'aide de LINQ-to-SQL, comme un exemple, le DataContext serait le contrôleur d'exposer un point de vue de la Clientèle et de l'Ordre des entités. La vue est un non-déclarative, cadre orientée type de Table (équivalent au Dépôt). Notez que la vue conserve une référence à son contrôleur de parent, et passe souvent par le contrôleur pour contrôler comment/quand la vue est matérialisé. Ainsi, le contrôleur est votre fournisseur, en prenant soin de la cartographie, de la traduction, de l'objet de l'hydratation, etc. Le modèle est ensuite vos données POCOs. Assez bien typique d'un modèle MVC.
À l'aide de N/Hibernate par exemple, le ISession serait le contrôleur d'exposer un point de vue de la Clientèle et des commandes entités par le biais de la session.Énumérable(string query) ou de la session.Get(object id) ou de la session.CreateCriteria(typeof(Client)).Liste()
Dans la logique métier du monde...
Customer { /*...*/ }
Employee { /*...*/ }
Repository<T> : IRepository<T>
, IEnumerable<T>
//, IQueryable<T>, IQueryProvider //optional
{ /**/ }
BusinessController {
Repository<Customer> Customers { get{ /*...*/ }} //aggregate root
Repository<Order> Orders { get{ /*...*/ }} // aggregate root
}
En un mot, laissez vos processus d'affaires et les transactions d'être le guide, et laissez votre infrastructure d'entreprise évoluent naturellement comme des processus/activités sont mises en œuvre ou remaniée. Par ailleurs, préférez la composabilité par rapport à la traditionnelle boîte noire de la conception. Lorsque vous arrivez à axées sur le service ou le cloud computing, vous serez heureux vous avez fait. :)
