Question

So, I’ve looked at some posts about the Specification Pattern here, and haven’t found an answer to this one yet.

My question is, in an n-layered architecture, where exactly should me Specifications get “newed” up?

1. I could put them in my Service Layer (aka, Application layer it’s sometimes called… basically, something an .aspx code-behind would talk to), but I feel like by doing that, I’m letting business rules leak out of the Domain. If the Domain objects are accessed some other way (besides the Service Layer), the Domain objects cannot enforce their own business rules.

2. I could inject the Specification into my Model class via constructor injection. But again, this feels “wrong”. I feel like the only thing that should be injected into Model classes are “services”, like Caching, Logging, dirty-flag tracking, etc… And if you can avoid it, to use Aspects instead of littering the constructors of the Model classes with tons of service interfaces.

3. I could inject the Specification via method injection (sometimes referred to as “Double Dispatch”???), and explicitly have that method encapsulate the injected Specification to enforce its business rule.

4. Create a “Domain Services” class, which would take a Specification(s) via constructor injection, and then let the Service Layer use the Domain Service to coordinate the Domain object. This seems OK to me, as the rule enforced by the Specification is still in the “Domain”, and the Domain Service class can be named very much like the Domain object it’s coordinating. The thing here is I feel like I’m writing a LOT of classes and code, just to “properly” implement the Specification pattern.

Add to this, that the Specification in question requires a Repository in order to determine whether it’s “satisfied” or not.

This could potentially cause performance problems, esp. if I use constructor injection b/c consuming code could call a property that perhaps wraps the Specification, and that, in turn is calling the database.

So any ideas/thoughts/links to articles?

Where is the best place to new up and use Specifications?

Answer 1

Short answer:

You use Specifications mainly in your Service Layer, so there.

Long answer:
First of all, there’s two questions here:

Where should your specs live, and where should they be new’d up?

Just like your repository interfaces, your specs should live in the domain layer, as they are, after all, domain specific. There’s a question on SO that discusses this on repository interfaces.

Where should they be new’d up though? Well, I use LinqSpecs on my repositories and mostly ever have three methods on my repository:

public interface ILinqSpecsRepository<T>
{
    IEnumerable<T> FindAll(Specification<T> specification);
    IEnumerable<T> FindAll<TRelated>(Specification<T> specification, Expression<Func<T, TRelated>> fetchExpression);
    T FindOne(Specification<T> specification);
}

The rest of my queries are constructed in my service layer. That keeps the repositories from getting bloated with methods like GetUserByEmail, GetUserById, GetUserByStatus etc.
In my service, I new-up my specs and pass them to the FindAll or FindOne methods of my repository. For example:

public User GetUserByEmail(string email)
{
    var withEmail = new UserByEmail(email); // the specification
    return userRepository.FindOne(withEmail);
}

and here is the Specification:

public class UserByEmail : Specification<User>
{
    private readonly string email;

    public UserByEmail(string email)
    {
        this.email = email;
    }

    #region Overrides of Specification<User>

    public override Expression<Func<User, bool>> IsSatisfiedBy()
    {
        return x => x.Email == email;
    }

    #endregion
}

So to answer your question, specs are new’d up in the service layer (in my book).

I feel like the only thing that should be injected into Model classes
are “services”

IMO you should not be injecting anything into domain entities.

Add to this, that the Specification in question requires a Repository
in order to determine whether it’s “satisfied” or not.

That’s a code smell. I would review your code there. A Specification should definitely not require a repository.