Hi Brendan - the unit test problem I have encountered with injecting Dao interfaces into the Domain is that when I have some method that does something with that Dao, I do not know which of its methods I need to fill with my fake data.
An example: My ICustomerDao has a GetById() method and a GetCustomersByCity() method. My Domain object has a method that in its implementation needs to use the ICustomerDao - which of the two methods do I provide with fake data? Now consider if the ICustomerDao has 19 methods. It would be easier for me if the method relying on the ICustomerDao instead required me to provide it with the actual Customer instances. A Mock object would not solve this issue. You would still need to know which of the 19 methods to fill with fake data. To solve the problem with the "complex" validation that you are describing - I think I would create a ValidateThatPatientHaveAccessCommand class, that performs all of this validation. My reasoning to create a separate class is that seems to be a fairly complex validation, that spans several other domain objects, whereas the actual state change in the domain object might be fairly simple. I myself is also struggling with these issues, and I am still learning. Thomas On 29 Aug., 19:06, Brendan Erwin <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
