J'ai étudié l'architecture d'oignon pendant quelques jours. Je comprends que les dépendances devraient toujours aller vers le centre et comment utiliser l'injection de dépendance pour y accomplir. Mais j'ai quelques questions que je ne pouvais toujours pas comprendre.
peut-il faire référence à un modèle (ou en entité) une interface de référentiel ou une interface de service? p>
EG: Un J'ai le code suivant dans mon modèle p>
Quels seraient les problèmes du code ci-dessus? Devrait-il utiliser un service de domaine à la place? P> li>
Si les implémentations de services de domaine doivent être définies à l'intérieur du noyau ou de la couche d'infrastructure? P> LI>
ol> p> L'entité code> a une relation DeliveryCity code> établi via oder.deliveryzip code> propriété, qui est icityrepository.findbyzip (zip) code> p>
class Order
{
. . .
[Inject]
public ICityRepository CityRepository { get; set; }
private City _dCity;
public City DeliveryCity {
get {
if (_dCity == null)
_dCity = this.CityRepository.FindByZip(this.DeliveryZip);
return _dCity;
}
}
. . .
}
3 Réponses :
Quels seraient les problèmes du code ci-dessus? Devrait-il utiliser un service de domaine à la place?
Deux choses à considérer ici:
iCityRepository n'est pas une dépendance réelle pour la commande, en d'autres termes, la commande n'en a pas besoin pour ses autres méthodes. La véritable dépendance est quelque chose que l'objet ne peut pas fonctionner sans. Donc, vous voudrez peut-être envisager de le transmettre comme paramètre à la méthode comme 'getdeliveryCity ' (voir Ceci pour plus de détails).trouver la ville par code postal ne semble pas une responsabilité de la commande. Pour être cohésive Il doit uniquement traiter les fonctionnalités liées à la commande. Vous voudrez peut-être prendre cette fonctionnalité de la classe d'ordre.
Si les implémentations de services de domaine doivent être définies à l'intérieur du noyau ou à la couche d'infrastructure?
à l'intérieur du noyau s'il s'agit d'un service vraiment de domaine (pas de service d'application).
Que diriez-vous de p>
private Lazy<City> _dCityLazy;
public City DeliveryCity {
get {
return _dCityLazy.Value;
}
}
L'injection de la ville à travers un CIO conduirait à ajouter des règles commerciales à l'injecteur de dépendance, ce qui est vraiment mauvais. Je ne suis pas sûr que c'est ce que vous avez proposé cependant.
Bien sûr, les règles commerciales dans l'injecteur de dépendance sont vraiment mauvaises, mais cela n'a pas besoin d'être ainsi. Il y a beaucoup d'autres possibilités. Il peut y avoir un service de domaine entre les deux. Ou, des regards d'identification simples sont évidemment le travail d'un référentiel, portant la méthode réelle d'où le délégué du paresseux
C'est là que les usines entrent dans le domaine. Une ordonnance de commande peut prendre des dépendances, telles qu'une dépendance sur l'iordopository, ainsi qu'une dépendance à l'égard de l'orifice. Lorsque l'usine est utilisée pour créer (ou reconstituer) une entité de commande, l'usine peut rechercher la ville et définir la propriété de commande en conséquence. Ou, comme l'indique Herzmeister, réglez-le à l'aide de paresseux afin que la recherche ne soit effectuée que si nécessaire.
Cela fait un sens parfait! Je me demande "comment puis-je manquer ça?"! Merci!
C'est une erreur. L'usine DDD n'est pas responsable de la reconstitution. La reconstitution est la vie moyenne d'un objet, l'usine n'est concernée que du début de la vie. S'il vous plaît voir cette réponse: Stackoverflow.com/a/10264669/625332
Je ne suis pas d'accord. Les usines sont utilisées pour créer des instances d'un objet. Ils peuvent être au début du cycle de vie d'un objet ou utilisé pour la reconstitution. Ils peuvent être la même classe avec deux méthodes ou deux classes différentes. De toute façon, je suis d'accord pour dire qu'il y a une différence dans la façon dont l'usine se comporte dans chaque cas. J'ai généralement l'usine de reconstitution comme une dépendance du référentiel qui déléguette à l'usine de créer et de reconstituer la nouvelle instance avec les données extraites du magasin de données. Pour plus d'informations, voir Evans PG 145: "Reconstituer des objets stockés"