Meilleure approche pour la construction de NHibernate DTO

Question

Je suis nouveau à NHibernate (et ORMES) et d'essayer de venir à bout de la myriade de différentes options qu'il présente. Pour référence, j'utilise Fluent NHibernate avec des objets séparés d'affaires qui à leur tour utilisent uniquement pour l'accès aux données de DTO. Mon architecture d'application doit prendre en charge les deux fenêtres et Web « extrémités avant ».

Mon quandry est une approche générale, car il semble y avoir tellement d'options. regard de quelque chose de mon DTO comme l'exemple ci-dessous. Chaque DTO a une référence à un ISession qui est passé à eux de la BO. Ils sont responsables de leur propre charge et enregistrer:

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

Tout d'abord: Est-ce la bonne approche à prendre - si le DTO ont la possibilité d'enregistrer et charger lui-même

En second lieu: Peu importe où le code sauvegarde / chargement se trouve, si vous utilisez le même ISession pour la durée de vie ou d'un objet, ou devraient-ils avoir un arbitre au ISessionFactory et ouvrir une nouvelle session toutes les interactions de base de données de temps est nécessaire?

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

Bien sûr, il y a toujours l'option 3, aucune de ce qui précède:)

Answer 1

En général, DTO ne contiennent pas de comportement (comme Save, Load) et ne contiennent pas la connaissance de la façon dont ils sont persistaient (ISession). Il ressemble à ce que vous créez est vraiment une couche de données. Votre couche d'affaires devrait idéalement pas connaître ISession non plus. Cela dit, vous pouvez raccourci cette superposition tout ce que vous voulez que cela correspond à vos besoins, mais il sera probablement difficile de passer à un autre ORM plus tard si votre ORM saigne à travers toutes vos couches.

Pour la gestion de la vie ISession, vous devez décider si vous allez utiliser le modèle UnitOfWork, qui dit essentiellement chaque demande de l'utilisateur obtient un nouveau ISession. Il existe d'autres options pour la vie ISession aussi bien et vous êtes vraiment pas limités à cet égard. Souvent, il peut y avoir des meilleures pratiques autour des applications Web par rapport aux applications Windows contre tout autre type d'application, mais vous ne spécifiez que vous écrivez.

Answer 2

Gardez votre code de chargement / enregistrement séparé de votre DTO. Les vues des objets DTO ne sont des données sous-jacentes.

Quand vous faites vos requêtes, retournez les DTO en utilisant une transformation. Quelque chose comme ceci:

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

Answer 3

années DTO sont destinés à être des « objets de transfert de données ». C'est, les objets muets utilisés pour passer des valeurs ou des collections de valeurs autour de votre système. Ils ne devraient pas être responsables d'eux-mêmes persistant, ou même la carte 1-1 aux objets de domaine dans votre couche de domaine.

Answer 4

Le ISession est très bon marché pour ouvrir / fermer. Le problème avec le garder ouvert est trop longtemps que la piscine de connexion ne peut pas réutiliser la connexion jusqu'à ce qu'il arrive à expiration ou que non. Cela pourrait être un problème dans une application multi-utilisateur.

Dans votre scénario, je serais probablement aller pour une approche orientée services pour stocker récupérer les données. qui signifie que le DTO ne sera utilisée en interne dans les limites de service. Si vous avez besoin de copier des objets qui ont le même aspect que je vous suggère de jeter un oeil à AutoMapper qui a été créé pour dans ce but précis. Si vous avez une fenêtre ou uniquement web projet alors il est pas un problème. Il est quand vous mélangez. Vous ne pouvez pas gérer les sessions de la même manière dans une application Windows comme dans une application Web.