Scope of Class in Domain Layer

Question

In my domain layer, I have a class called 'Client'. Normally I would only create properties that directly relate to that client in the class, eg - 'Firstname', 'Lastname', 'Address' etc.. as well as client related methods.

My question is, would it be considered bad OO design to add a method to this class that performs work on a collection of clients?

E.g. - lets say that there is an operation that I want to perform on a Client such as updating their email address. Before I will do this I want to make sure there are no other clients with the same email address so I create a method off the Client class called ValidateEmail(string emailAddress).

Inside this method a repository of Clients is queried for any existing client with that email address and returns a boolean value.

Would this be considered bad OO design? I would rather not have to create any other classes or fill up the UI layer - controller logic with this validation and it seems to fit the Client class however it feels like performing operations on siblings isnt quite right..

Thanks

Answer 1

If it were me, I would have a ClientCollection class. You pretty much have this anyway in all but name, so I don't see it as any big deal.

As part of that class I might have a method called GetClientsWithEmail, which returns a list of Clients with a particular email address. By doing things this way, this method is purely a lookup, doesn't contain any business logic. In fact I could envisage a single line of linq under here.

When someone tries to update the email address of the Client, you will have some validation code. This may or may not be part of the Client class (you indicate that it is, but it doesn't have to be of course). Anyway, this validation code can call ClientCollection.GetClientsWithEmail method, and test that the returned number of Client objects is zero.