Вопрос

Я новичок в NHibernate (и ORMS) и пытаюсь разобраться с множеством различных вариантов, которые он предлагает.Для справки: я использую Fluent NHibernate с отдельными бизнес-объектами, которые, в свою очередь, используют DTO исключительно для доступа к данным.Архитектура моего приложения должна поддерживать как Windows, так и веб-интерфейсы.

Моя загадка связана с общим подходом, поскольку вариантов, кажется, очень много.Мой DTO выглядит примерно так, как показано ниже.Каждый DTO имеет ссылку на ISession, которая передается ему из BO.Они отвечают за собственную нагрузку и экономию:

public class EmployeeDTO...

    // Data Properties to be persisted to the database
    public virtual int Id { get; private set; }
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; }
    public virtual ISession Session { get; set; }

    // Save logic
    public virtual void Save()
    {
        var transaction = Session.BeginTransaction();
        Session.SaveOrUpdate(this);
        transaction.Commit();
    }

    // Load logic
    public virtual void Load(int id)...

Прежде всего:Правильный ли это подход - должен ли DTO иметь возможность сохранять и загружать себя?

Во-вторых:Независимо от того, где находится код сохранения/загрузки, следует ли вам использовать один и тот же ISession для всего времени существования или объекта, или они должны иметь ссылку на ISessionFactory и открывать новый сеанс каждый раз, когда требуется взаимодействие с базой данных?

    // Open a new session every time I interact with the repository
    var session = FluentSupport.SessionFactory.OpenSession();
    var transaction = Session.BeginTransaction();
    Session.SaveOrUpdate(this);
    transaction.Commit();
    session.Close();
    // Close the session when I'm done

Конечно, всегда есть вариант 3, ничего из вышеперечисленного :)

Это было полезно?

Решение

В общем, DTO не содержат поведения (например, «Сохранить», «Загрузить») и не содержат сведений о том, как они сохраняются (ISession).Похоже, вы на самом деле создаете уровень данных.В идеале ваш бизнес-уровень также не должен знать об ISession.Тем не менее, вы можете сокращать эти слои по своему усмотрению, если они соответствуют вашим потребностям, но, скорее всего, позже будет сложно перейти на другой ORM, если ваш ORM будет проникать через все ваши слои.

Для управления жизненным циклом ISession вам необходимо решить, будете ли вы использовать шаблон UnitOfWork, который, по сути, гласит, что каждый пользовательский запрос получает новый ISession.Существуют и другие варианты времени жизни ISession, и вы действительно не ограничены в этом отношении.Часто могут существовать лучшие практики в отношении веб-приложений и веб-приложений.Windows-приложения против.любые другие типы приложений, но вы не указали, какие именно пишете.

Другие советы

Держите код загрузки/сохранения отдельно от DTO.Объекты DTO являются только Просмотры базовых данных.

При выполнении запросов возвращайте DTO с помощью преобразования.Что-то вроде этого:

resultSet = session.CreateCriteria(typeof(MyDataObject))
    .Add(query criteria, etc.)
    .SetResultTransformer(Transformers.AliasToBean<MyDTOObject>())
    .List<IMyDTOObject>()

DTO считаются «объектами передачи данных».То есть «глупые» объекты, используемые для передачи значений или коллекций значений в вашей системе.Они не должны нести ответственность за сохранение себя или даже сопоставлять 1-1 с объектами домена на вашем уровне домена.

Открытие/закрытие ISession обходится очень недорого.Проблема с тем, чтобы держать его открытым слишком долго, заключается в том, что пул соединений не может повторно использовать соединение до тех пор, пока не истечет время ожидания или что-то еще.Это может быть проблемой в многопользовательском приложении.

В вашем сценарии я бы, вероятно, выбрал сервис-ориентированный подход для хранения полученных данных.это означает, что DTO будет использоваться только внутри границ службы.Если вам нужно скопировать объекты, которые выглядят одинаково, я предлагаю вам взглянуть на АвтоМаппер который был создан именно для этой цели.Если у вас есть проект только для Windows или только для Интернета, это не проблема.Это когда вы смешиваете.Вы не можете обрабатывать сеансы в приложении Windows так же, как и в веб-приложении.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top