In this particular case I think I got my example a bit confused. You
are right, _Patient_ doesn't need to do the validation, but Visit does.
And, although the method you propose would be nice to have when
creating Visits, they still need to be re-validated at many other
points in their life-cycle. So its not quite enough to pre-validate
like you propose.
Also, I don't think I share your distinction between "validation" and
"business logic". The domain(type) of attributes (simple validation)
is just as much a part of the Business Domain as is the relationships
between entities. I view validation more a a pattern to follow in
order to ask if everything is ok, not limited to attribute domain.
(But thanks for the cool "GetPossibleSchedulesFor" idea. I'm sure it
will find its way into things...)
----
RE: Aggregate Roots. I think I might have broken this concept
somewhat. (Or maybe not, you tell me.) As I mentioned before, I found
that the fairly simple collection semantics that my associations were
being forced into just weren't gonna cut it. They would have required
that I load _way_ to much stuff from the DB to do the checks I need
to. So, I started removing those collections from my Entities and
moved towards accessing them via the DAOs. That solved the semantics
and performance problems since I can now do my set operations in the
DB, but I lost a great deal of discoverability in my API/DSL and now I
think I need DI of DAOs to get it back. (Full circle: back to the
original question.)
On Aug 29, 2009, at 5:24 PM, Belvasis wrote:
> I don't think they are in the same aggregate root. The available
> doctors, the services
> they are providing, the rooms visits my be scheduled in etc. are
> independent
> from the Patient entity. But i think the Patient entity or the
> PatientVisit entity
> must not know anything about relationships between doctors,
> services, rooms
> etc. so all this has nothing to do with validation i think. Isn't it
> easier to have
> something like
>
> public interface IScheduleVisitService
> {
> IList<IVisitSchedule> getPossibleSchedulesFor( VisitKind i_Kind,
> DateTime i_dtWhen);
> }
>
> with
>
> public interface IVisitSchedule
> {
> IList<IDoctor> Doctors { set;get;}
> IRoom Room { set;get;}
> DateTime Date { set;get;}
> DateTime Time { set;get;}
> }
>
> So a user can choose from pre - validated Schedules provided by the
> IScheduleVisitService and there
> is no need to do any validation within the Patient entity. In the
> end this is no validation but real
> bussines logic. Or do i understand something wrong?
>
> Regards
>
>
> 2009/8/29 Greg Young <[email protected]>
>
> > 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?
>
> It sounds to me like these objects are in the same aggregate root.
>
> Aggregate roots are complex beasts that bring out much of the hidden
> complexity in other architectures (which is often forgotten) ... An
> example of this would be if you are doing this all in the database
> with queries as you mention how do you insure consistency?
>
> Generally speaking aggregate roots are loaded as a whole (EG the main
> object and its children are loaded). The use case is performed and
> then the aggregate is saved (with versioning happening on the root
> object which insures consistency).
>
> For a *lot* more information on this subject check out Domain Driven
> Design by Eric Evans (its a whole book covering these types of issues)
>
> Greg
>
> On Sat, Aug 29, 2009 at 1:06 PM, 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
> >>
> >> >
> >
> >
> > >
> >
>
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
