Thanks for the conversation! The reasoning behind it is that I want to put my domain manipulation behaviors in my domain models but the semantics offered by simple association-collections are not rich enough for us. (not to mention downright dangerous when actually connected to a database.)
An example of the type of operation that this would make easier is validation: I have some entities that are only valid if certain associations are in particular shapes, i.e. a patient visit can be associated with many services and many doctors, but all the services have to be compatible with all the doctors. That sort of validation requires that I make queries into my data store if it is going to be efficient, right? Raul and Thomas, would you suggest a "sidecar" class to do my validation then? And would the DAO be injected into that class? (BTW, I agree injecting a factory would be dangerous, if it was able to create multiple types.) Greg, can you offer some alternatives using this problem as an example? Thomas, speaking to the test fragility problem, if I provide a mock DAO that is pre-loaded with the data I expect how is that different from pre-loading the association collections on an entity? On Aug 29, 2009, at 12:56 PM, Thomas Koch wrote: > > Hi Brendan - in my experience, injecting DAOs into the domain model > does make it a little more difficult to unit-test your domain model. > > I agree with Stuart that you should use the interface for the DAO when > doing this. > > However, consider the situation where your DAO has a large number of > methods and you want to unit test a part of your domain model that > needs the DAO. It now becomes difficult to determine how many of the > DAO inteface members you actually need to provide an implementation > for, without actually looking at the code under test. Moreover as time > goes by, you tend to forget the details, which in turn causes the > tests to be difficult to understand. > > Having injected DAO into the domain model in the past, I am now trying > to avoid it. At one point I actually injected the whole DaoFactory > into the domain model. It turned out to be a very bad call, as it > became very difficult to test anything. > > Instead, I sometimes create "Command" objects which I guess is > equivalent to Rauls "components." > > Hope this helps. :-) > > Regards > Thomas On Aug 29, 2009, at 12:40 PM, Raul Carlomagno wrote: > > i think you should not inject daos into yout business entities, i like > the concept about single responsability, so, if your biz entities > define your business domain you are adding an extra responsability, to > access repositories, so, i would define extra classes to manage > business interactions, for example, Customer is your POCO and then we > will have the CustomerComponent class which does business logic > related to customers, for example FindAll(), DeleteCustomer(), send > email about a new product to a customer (SendEmailForNewProduct()), > components are defined into the architecture proposed by microsoft > for .net applications, and of course you need to innject daos or > repositories into your components to be able to access to a repository > of data On Aug 29, 2009, at 12:42 PM, Greg Young wrote: > > I would re-think your reasons for wanting to inject them in the first > place as there are often better ways of doing the same thing. > > Greg > > On Fri, Aug 28, 2009 at 10:09 PM, Brendan Erwin<[email protected] > > wrote: >> I'm thinking of wiring up StructureMap to provide IoC within NH so >> I can >> inject my DAOs into my domain models. >> In doing the research I see a lot of people speaking out against >> having >> dependencies in ones domain, but the way I see it my data access >> strategies >> and policies are part of my domain. How wrong am I? >>> >> > > > > -- > Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer > de votre attention > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
