C # MongoDB: comment cartographier correctement un objet de domaine?

j'irais avec l'analyse des documents BSON et je déplacerais la logique d'analyse dans une usine.

définir D'abord une classe de base d'usine, qui contient une classe de constructeur. La classe builder agira comme DTO, mais avec validation supplémentaire des valeurs avant de construire l'objet domain.

public class TransportFactory<TSource>
{
    public Transport Create(TSource source)
    {
        return Create(source, new TransportBuilder());
    }

    protected abstract Transport Create(TSource source, TransportBuilder builder);

    protected class TransportBuilder
    {
        private TransportId transportId;
        private PersonCapacity personCapacity;

        internal TransportBuilder()
        {
        }

        public TransportBuilder WithTransportId(TransportId value)
        {
            this.transportId = value;

            return this;
        }

        public TransportBuilder WithPersonCapacity(PersonCapacity value)
        {
            this.personCapacity = value;

            return this;
        }

        public Transport Build()
        {
            // TODO: Validate the builder's fields before constructing.

            return new Transport(this.transportId, this.personCapacity);
        }
    }
}

maintenant, créez une sous-classe d'usine dans votre dépôt. Cette usine construira des objets de domaine à partir des documents BSON.

public class TransportRepository
{
    public Transport GetMostPopularTransport()
    {
        // Query MongoDB for the BSON document.
        BsonDocument transportDocument = mongo.Query(...);

        return TransportFactory.Instance.Create(transportDocument);
    }

    private class TransportFactory : TransportFactory<BsonDocument>
    {
        public static readonly TransportFactory Instance = new TransportFactory();

        protected override Transport Create(BsonDocument source, TransportBuilder builder)
        {
            return builder
                .WithTransportId(new TransportId(source.GetString("transportId")))
                .WithPersonCapacity(new PersonCapacity(source.GetInt("personCapacity")))
                .Build();
        }
    }
}

Les avantages de cette approche:

• Le constructeur est responsable de la construction de l'objet de domaine. Cela vous permet de déplacer une validation triviale hors de l'objet domain, surtout si l'objet domain n'expose aucun constructeur public.
• l'usine est responsable de l'analyse des données source.
• l'objet domaine peut se concentrer sur les règles d'affaires. Il n'est pas gêné par l'analyse ou la validation triviale.

• la classe d'usine abstraite définit contrat générique, qui peut être mis en œuvre pour chaque type de données source dont vous avez besoin. Par exemple, si vous avez besoin d'une interface avec un service web qui renvoie XML, il vous suffit de créer une nouvelle sous-classe d'usine:

  public class TransportWebServiceWrapper
  {
      private class TransportFactory : TransportFactory<XDocument>
      {
          protected override Transport Create(XDocument source, TransportBuilder builder)
          {
              // Construct domain object from XML.
          }
      }
  }
  

• la logique d'analyse des données source est proche de l'origine des données, c'est-à-dire que l'analyse des documents BSON se trouve dans le dépôt, L'analyse XML se trouve dans le wrapper du service web. Cela permet de grouper les logiques liées. ainsi.

inconvénients:

• Je n'ai pas encore essayé cette approche pour des projets complexes et de grande envergure, mais seulement pour des projets à petite échelle. Il peut y avoir des difficultés dans certains scénarios que je n'ai pas encore rencontrés.
• c'est tout un code pour quelque chose apparemment simple. Surtout les constructeurs peuvent se développer assez grand. Vous pouvez réduire la quantité de code dans les constructeurs en convertissant tous les WithXxx() méthodes simples propriété.

une meilleure façon d'aborder cette question consiste maintenant à utiliser MapCreator (qui a peut-être été ajouté après que la plupart de ces réponses aient été écrites).

par exemple, j'ai une classe appelée Time avec trois propriétés readonly: Hour,Minute et Second. Voici comment je l'obtenir pour stocker ces trois valeurs dans la base de données et de construire de nouvelles Time objets lors de la désérialisation.

BsonClassMap.RegisterClassMap<Time>(cm =>
{
    cm.AutoMap();
    cm.MapCreator(p => new Time(p.Hour, p.Minute, p.Second));
    cm.MapProperty(p => p.Hour);
    cm.MapProperty(p => p.Minute);
    cm.MapProperty(p => p.Second);
}

Consider NoRM, un ORM open-source pour MongoDB in C#.

Voici quelques liens:

http://www.codevoyeur.com/Articles/20/A-NoRM-MongoDB-Repository-Base-Class.aspx

http://lukencode.com/2010/07/09/getting-started-with-mongodb-and-norm/

https://github.com/atheken/NoRM (télécharger)

Niels a une solution intéressante mais je propose une approche très différente: Simplifiez votre modèle de données.

je dis cela parce que vous essayez de convertir les entités de style RDBMS en MongoDB et cela ne correspond pas très bien, comme vous l'avez trouvé.

une des choses les plus importantes à considérer lors de l'utilisation d'une solution NoSQL est votre modèle de données. Vous avez besoin de libérer votre esprit de beaucoup de ce que vous savez sur SQL et les relations et de penser plus sur les documents incorporés.

et rappelez-vous, MongoDB n'est pas la bonne réponse pour chaque problème alors essayez de ne pas le forcer à l'être. Les exemples que vous suivez peuvent très bien fonctionner avec des serveurs SQL standards mais ne vous tuez pas en essayant de comprendre comment les faire fonctionner avec MongoDB - ils ne le font probablement pas. Au lieu de cela, je pense qu'un bon exercice serait d'essayer de trouver la bonne façon de modéliser les données de L'exemple avec MongoDB.