Специальные данные и шаблон репозитория

В этом вопросе многое. Вам нужны эти конкретные данные для процедуры отчетности? Если это так, то правильное решение состоит в том, чтобы иметь отдельный доступ к данным для целей отчетности. Сглаженные базы данных, представления и т. д.

Или это специальный запрос? Если да, то у Ayende есть пост по этой самой проблеме. http://ayende.com/Blog/archive/2006/12/07/ComplexSearchingQueryingWithNHibernate.aspx

Он использует объект «Искатель». Он использует NHibernate, поэтому, по сути, он создает отдельный запрос.

Я делал что-то подобное в прошлом, создавая объект Query, который я могу заполнить перед передачей его в репозиторий (некоторые сторонники DDD будут возражать против этого, но я нахожу его элегантным и простым в использовании).

Объект Query реализует гибкий интерфейс, поэтому я могу написать это и получить результаты обратно:

IQuery query = new PostQuery()
   .WithPostId(postId)
   .And()
   .WithCommentCount()
   .And()
   .WithCommentsHavingDateLessThan(selectedDate);


Post post = _repository.Find(query);

Однако в вашем конкретном случае я должен удивиться вашему дизайну. Вы говорите, что не можете загрузить комментарии к посту. Почему? Вы просто слишком беспокоитесь о производительности? Является ли это случаем преждевременной оптимизации? (мне кажется)

Если бы у меня был объект Post, это был бы мой совокупный корень, и к нему прилагались бы комментарии. И тогда все, что вы хотите сделать, будет работать в каждом сценарии.

Поскольку нам нужно было срочно решить проблему, которую я изложил в своем первоначальном вопросе, мы прибегли к следующему решению. Мы добавили набор свойств (словарь) к каждому объекту модели, и, если это необходимо, DAL вставляет в него пользовательские данные. Чтобы установить какой-то контроль, коллекция свойств управляется экземплярами назначенного класса и поддерживает только простые типы данных (целые числа, даты, ...), что все, что нам нужно при перемещении, и, скорее всего, когда-либо понадобится . Типичный случай, который это решает: загрузка сущности с подсчетами для ее вложенных коллекций вместо полных заполненных коллекций. Я подозреваю, что это, вероятно, не получает никакой награды за разработку программного обеспечения, но это было самое простое и практичное решение для нашего случая.

Не могу сказать, что я действительно понимаю, в чем проблема, просто стреляю в воздух:

• Добавьте конкретную сущность, чтобы инкапсулировать нужную информацию.
• Добавить свойство Комментарии к сообщению. (Я не понимаю, почему это потребует от вас получения всех комментариев — вы можете просто получить комментарии для конкретного сообщения, которое вы загружаете)
• Используйте ленивую загрузку, чтобы получать комментарии только при доступе к свойству.

Я думаю, у вас было бы больше шансов увидеть ответ на свой вопрос, если бы вы сделали платформу, язык и сопоставитель O/R специфичными (кажется, .NET C# или VB, поскольку вы упомянули LINQ. LINQ 2 SQL? Entity framework? Что-то еще ?)

Если вы не привязаны к RDBM, то вам стоит обратить внимание на такие базы данных, как CouchDB или Amazons SimpleDB. То, что вы описываете, тривиально в представлении CouchDB. Это, вероятно, на самом деле не отвечает на ваш конкретный вопрос, но иногда полезно взглянуть на радикально разные варианты.

Для этого у меня обычно есть RepositoryStatus и класс Status, который действует как мой объект передачи данных (DTO). Класс Status используется на моем уровне службы приложений (по той же причине), от которого наследуется RepositoryStatus. Затем с помощью этого класса я могу возвращать сообщения об ошибках, объекты ответа и т. д. из слоя репозитория. Этот класс является универсальным в том смысле, что он принимает любой объект и передает его получателю.

Вот класс состояния:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using RanchBuddy.Core.Domain;
using StructureMap;

namespace RanchBuddy.Core.Services.Impl
{
    [Pluggable("Default")]
    public class Status : IStatus
    {
        public Status()
        {
            _messages = new List<string>();
            _violations = new List<RuleViolation>();
        }

        public enum StatusTypes
        {
            Success,
            Failure
        }

        private object _object;
        public T GetObject<T>()
        {
            return (T)_object;
        }
        public void SetObject<T>(T Object)
        {
            _object = Object;
        }

        private List<string> _messages;
        public void AddMessage(string Message)
        {
            _messages.Add(Message);
        }
        public List<string> GetMessages()
        {
            return _messages;
        }
        public void AddMessages(List<string> Messages)
        {
            _messages.AddRange(Messages);
        }

        private List<RuleViolation> _violations;
        public void AddRuleViolation(RuleViolation violation)
        {
            _violations.Add(violation);
        }
        public void AddRuleViolations(List<RuleViolation> violations)
        {
            _violations.AddRange(violations);
        }
        public List<RuleViolation> GetRuleViolations()
        {
            return _violations;
        }
        public StatusTypes StatusType { get; set; }
    }
}

А вот RepositoryStatus:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using RanchBuddy.Core.Services.Impl;
using StructureMap;

namespace RanchBuddy.Core.DataAccess.Impl
{
    [Pluggable("DefaultRepositoryStatus")]
    public class RepositoryStatus : Status, IRepositoryStatus
    {

    }
}

Как видите, RepositoryStatus еще не делает ничего особенного и просто полагается на утилиты объектов Status. Но я хотел оставить за собой право продления на более поздний срок!

Я уверен, что некоторые из твердолобых скажут, что это не следует использовать, если вы хотите быть практиком... однако я знаю вашу боль в том, что иногда вам нужно передать больше, чем просто возвращенный объект!