Wouldn't the "which data do I provide" issue be moot in a TDD/BDD development scenario? In that case it seems there wouldn't be much confusion.
I suspect that I will need to convert my whole domain over to a Command Object pattern eventually. Each of the commands would represent a smaller chunk of behavior and for those I suppose it would be appropriate to inject the DAO. On Aug 29, 2009, at 1:37 PM, Thomas Koch wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
