Да, это определенно излишне, если вы ожидаете много клиентов.Вы можете использовать информацию в экземпляре вашей спецификации для генерации соответствующего SQL / HQL или ICreteria (при условии, что вы используете NHibernate).
public IList<Customer> FindCustomers(CreationDateRangeSpecification spec) {
ICriteria c = _nhibernateSession.CreateCriteria(typeof(Customer));
c.Add(Restrictions.Between("_creationDate", spec.Start, spec.End));
return c.List<Customer>();
}
Этот код немного менее выразителен, чем тот, который вы опубликовали, но все же хорош взахват некоторой информации о домене в спецификации.
При работе со спецификацией следует иметь в виду, что это концепция домена.Он относится к домену и должен быть свободен от технологий доступа к данным.Важны технические детали получения данных, они просто не важны на уровне домена, они относятся к уровню доступа к данным.На мой взгляд, такие вещи, как Expression<Func<Customer, bool>>
, являются «инфраструктурными» для кода домена.Кроме того, спецификации на основе Linq, как правило, требуют, чтобы доменные объекты представляли свои данные в виде свойств, что иногда нарушает их инкапсуляцию.Таким образом, все это может превратиться в «Linq over Anemic Model ».
Я настоятельно рекомендую вам прочитать DDD book .В нем есть глава, посвященная шаблону спецификации и всем компромиссам, с которыми вы имеете дело.