It seems to me that the question has shifted away from "should I/
shouldn't I inject DAOs into Entities" and more towards "how do I
divide up the domain model beyond simple Entities and DAOs in order to
deal with complex stuff".
I'll take that as some form of validation that I'm not on the wrong
track. (In addition to the outright statements to that affect...)
I did realize, after reading over Stuart's sample, that my validation
scenario didn't actually outgrow the collection semantics like I was
positing. How about this then, to further complicate the problem:
In addition to needing to validate that each Doctor assigned to a
Patient's Visit is able to perform each Service the Visit is for we
also need to ensure that the Doctors
assigned to the Visit will be at the Location the Visit is
assigned to during the time span the Visit is scheduled for.
So, whether I have a Validation method called on the Entity, a
Validation Command Object executed by the Entity, or a Validation
Service which receives the Entity, I think it's clear that the actor
will need to have the DAO injected. (It's also clear that testing this
sort of complex behavior is going to be difficult and will require a
fairly large amount of data/scenario setup.)
On Aug 29, 2009, at 4:13 PM, Stuart wrote:
>
> On Aug 29, 1:29 pm, Thomas Koch <[email protected]> wrote:
>>
>> How do you see/solve the "testability problem" that I was talking
>> about?
>>
>
> I can see how injecting DAOs into your domain could make testing
> problematic.
>
> Also, as I've reflected upon the code I posted earlier in this thread,
> I've come to hate it. :) I hate it because of the customer/order
> relationship, though -- not because of the principle I was trying to
> demonstrate. In other words, I still think it's okay to inject DAOs
> into your domain model, but I agree it's probably less than ideal.
>
> It's hard to talk about this stuff in the abstract. I like what you
> said about the problem of DAOs having lots of methods and it not being
> clear what's being used where. Creating fine-grained DAOs might help
> to mitigate that pain (Interface Segregation Principle if you want a
> label).
>
> Brendan's example had to do with validation. He has Doctors, Patients,
> Visits, and Services. A doctor can provide a certain set of services.
> A patient can receive multiple services during one visit, and those
> services may come from one or many doctors. If validation of these
> configurations is non-trivial then I would consider having a
> 'Validator' or 'ValidationService' or something along those lines.
>
> I'm having trouble envisioning the validation scenario, so I'll leave
> that aside for now. But based on what Brendan has mentioned I would
> think of something along these lines...
>
> public interface IServiceDao
> {
> IList<Service> GetServicesByDoctor(int doctorId);
> }
>
> public interface IDoctorDao
> {
> IList<Doctor> GetDoctorsByService(int serviceId);
> }
>
> public class Doctor
> {
> private IServiceDao _serviceDao;
>
> public IList<Service> GetServices()
> {
> return _serviceDao.GetServicesByDoctor(Id);
> }
>
> public int Id { get; set; }
> }
>
> public class Service
> {
> private IDoctorDao _doctorDao;
>
> public IList<Doctor> GetOfferingDoctors()
> {
> return _doctorDao.GetDoctorsByService(Id);
> }
>
> protected int Id { get; set; }
> }
>
> public class Visit
> {
> public IList<Doctor> Doctors { get; set; }
> public IList<Service> Services { get; set; }
> public Patient Patient { get; set; }
> }
>
> public class Patient
> { }
>
>
> --Stuart
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
