Есть ли смысл в абстрагировании критерия NHibernate?

Question

Я довольно новичок в NHibernate, и большинство примеров, которые я видел, добавляют некоторый уровень абстракции над базовыми Criterion или DetachedCriterion классами. В простых случаях это какие-то Query классы, которые могут выглядеть примерно так:

public class Query<T>
{
    public List<QueryCondition> Conditions { get; set;}
}

public class QueryCondition
{
    public string Property { get; set; }
    public ComparisonEnum Comparison { get; set; }
    public object Value { get; set; }
}

Где-то на уровне служб или хранилища эта абстракция запроса преобразуется в надлежащий Criterion объект, который затем используется NHibernate для извлечения записей.

Этот пример, конечно, является чрезмерным упрощением. В моем проекте я пошел по пути создания класса Query<T>, который будет содержать условия AND и OR, а интерфейс определяет метод для перевода моих пользовательских условий (которые в некоторых случаях намного сложнее, чем упрощенный QueryCondition пример выше) в AbstractCriterion для добавления к DetachedCriterion, встроенному в сервис. Одна из причин, по которой я это сделал, заключается в том, что я сохраняю связанные запросы, чтобы пользователи могли определить список и сохранить его, но самая большая причина в том, что он, кажется, является преобладающим методом для проектов n-уровня NHibernate, которые я видел.

Однако я начинаю задаваться вопросом, стоит ли накладные расходы на эту абстракцию. Это не спасает меня от зависимостей от NHibernate. Поскольку я использую фьючерсы для пакетных запросов, все мои проекты должны ссылаться на NHibernate, чтобы по крайней мере получить доступ к IFutureValue для подсчета записей. Кроме того, мой класс Query<T> неразрывно связан с NHibernate, так как он создает AbstractCriterion (хотя я мог бы легко перенести это в отдельный класс).

В любом случае, чем больше я на это смотрю, тем проще заменить Query<T> на DetachedCriteria. Оба они сериализуемы, поэтому я могу их сохранить, и, поскольку я не буду строить условия критерия отдельно от самого критерия, я думаю, что у меня меньше шансов столкнуться с проблемами псевдонимов для сложных запросов. А что касается абстракций, то эта, похоже, не дает много изоляции от сложности.

Может ли кто-нибудь объяснить мне, почему я должен абстрагироваться от критериев NHibernate , кроме «вы можете изменить свой ORM однажды» (что-то, что мне удобно говорить, невозможно на данном этапе проекта)?

Answer 1

Имеет преимущество с точки зрения модульного тестирования.Criteria API действительно хорош в построении запросов, но это настоящая боль для насмешек.Если у вас есть такой класс, вы легко проверяете условие:

 query.Conditions.Contains(requiredCondition);

В то время как в Criteria вам потребуются некоторые макеты и проверка поведения приложения, а не вывода, что намного сложнее.

Только по этой причине я все еще использую шаблон Repository в своих приложениях вместо того, чтобы просто ISession напрямую