El mejor enfoque para la construcción de NHibernate DTO del

Question

Soy nuevo en el NHibernate (y ORM) y tratando de venir a los apretones con la gran cantidad de diferentes opciones que presenta.Para referencia, estoy usando NHibernate fluent con separar los objetos de negocio que a su vez utilizan DTO puramente para el acceso a datos.Mi arquitectura de la aplicación debe soportar ambos windows y web "front-end".

Mi quandry es uno de planteamiento general como parece ser que hay tantas opciones.Mi DTO a ver algo como el ejemplo a continuación.Cada DTO tiene una referencia a un ISession que se pasa a ellos desde el BO.Ellos son responsables de sus propios cargar y guardar:

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)...

Primero de todo: Es esta la manera correcta de acercarse a tomar - si el DTO tiene la capacidad de guardar y cargar sí mismo?

En segundo lugar: Independientemente de donde guardar/cargar el código de mentiras, se debe utilizar el mismo ISession para toda la vida o un objeto, o deberían tener un ref para el ISessionFactory y abrir una nueva sesión cada vez que la base de datos es necesaria la interacción?

    // 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

Por supuesto, siempre hay la opción 3, ninguno de los de arriba :)

Answer 1

En general, las OTD no contienen el comportamiento (como Guardar, cargar) y no contienen el conocimiento de cómo hayan llegado persistieron (ISession). Suena como lo que realmente está creando es una capa de datos. Su capa de negocio idealmente no debería saber sobre ISession tampoco. Dicho esto, se puede atajar este capas todo lo que quiera y cuando se ajuste a sus necesidades, pero es probable que sea difícil cambiar a otro ORM más adelante si su ORM sangra a través de todas las capas.

Para la gestión de toda la vida ISession, usted tiene que decidir si va a utilizar el patrón UnitOfWork, que básicamente dice que cada petición de usuario recibe un nuevo ISession. Hay otras opciones para ISession vida, así y que realmente no se limitan a este respecto. A menudo, puede haber mejores prácticas en torno a las aplicaciones web frente a aplicaciones de Windows frente a cualesquiera otros tipos de aplicaciones, pero no se ha especificado el que estuviera escribiendo.

Answer 2

Mantenga su carga/ahorro de código independiente de la de sus DTOs.El DTO objetos son sólo vistas de los datos subyacentes.

Al hacer sus consultas, devolver el Dto mediante una transformación.Algo como esto:

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

Answer 3

de DTO están destinados a ser "objetos de transferencia de datos". Es decir, los objetos mudos utilizados para introducir valores o colecciones de valores en torno a su sistema. No deben ser responsables de la persistencia de sí mismos, o incluso un mapa 1-1 a los objetos de dominio en la capa de dominio.

Answer 4

El ISession es muy barato para abrir / cerrar. El problema con mantenerlo abierto durante demasiado tiempo es que la agrupación de conexiones no se puede reutilizar la conexión hasta que el tiempo de espera o lo que no. Esto podría ser un problema en una aplicación multiusuario.

En el escenario probablemente me vaya para un enfoque orientado al servicio para almacenar recuperar datos. es decir, el DTO sólo se utiliza internamente dentro de los límites del servicio. Si necesita copiar objetos que tienen el mismo aspecto que sugiera que echar un vistazo a AutoMapper que fue creado para este propósito específico. Si sólo tiene un único proyecto o una ventana web entonces no es un problema. Es cuando se mezclan. No se puede manejar las sesiones de la misma manera en una aplicación de Windows como en una aplicación Web.