If the name of the test makes it clear how the Dao is used within the test, then of course it is not a problem using the daos in the domain model.
I also inject DAOs into my command objects, but when you think about it, the same test problem still applies. I do not know about moving all of the domain logic to Command objects. It seems to me that some logic fits well with Command objects whereas other types of logic is best kept inside the domain model. For instance, I usually keep the logic for adding/removing objects from lists (bags) inside the domain, whereas complex logic, spanning several domain objects, go into Command objects. At the end of the day, I guess it boils down to "whatever works for you". :) Cheers, Thomas On 29 Aug., 19:51, Brendan Erwin <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
