Использование хранилища между моделью EF и потребителем кода

Question

У меня есть двоичные данные в моей базе данных, которые в какой-то момент мне придется преобразовать в растровое изображение. Я думал, уместно ли использовать репозиторий и делать это там. Мой потребитель, который является уровнем представления, будет использовать этот репозиторий. Например:

// This is a class I created for modeling the item as is.
public class RealItem
{
    public string Name { get; set; }
    public Bitmap Image { get; set; }
}

public abstract class BaseRepository
{
    //using Unity (http://unity.codeplex.com) to inject the dependancy of entity context.
    [Dependency]
    public Context { get; set; }
}

public calss ItemRepository : BaseRepository
{
    public List<Items> Select()
    {
        IEnumerable<Items> items = from item in Context.Items select item;
        List<RealItem> lst = new List<RealItem>();
        foreach(itm in items)
        {
            MemoryStream stream = new MemoryStream(itm.Image);
            Bitmap image = (Bitmap)Image.FromStream(stream);
            RealItem ritem = new RealItem{ Name=item.Name, Image=image };
            lst.Add(ritem);
        }

        return lst;
    }
}

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

public IQueryable<object> Select
{
    return from q in base.Context.MyItems select q;
}

Как вы можете видеть, в их подход к системе практически не добавляется поведение, за исключением скрытия запроса доступа к данным, поэтому я был озадачен тем, что, возможно, хранилище - это нечто другое, и я все понял неправильно. В конце должны быть дополнительные преимущества их использования, верно?

Обновление: оказалось, что вам не нужны репозитории, если с данными ничего не нужно делать перед их отправкой, но подождите! нет абстракции по запросу LINQ? Таким образом, клиент должен предоставить нам операторы запросов, которые могут быть немного небезопасными и трудными для проверки, поэтому, возможно, хранилище также предоставляет абстракцию для запросов данных? если это правда, то наличие репозитория всегда является необходимой потребностью в архитектуре проекта !! однако эта абстракция может быть предоставлена ​​с помощью хранимых процедур SQL. какой выбор, если доступны оба варианта?

Answer 1

Да, это правильный путь: контракт репозитория удовлетворяет потребности приложения, имея дело только с объектами приложения.

(Плохой) пример, который вы видите большую часть времени, связывает любую реализацию репозитория с IQueryable, которая может или не может быть реализована нижележащим orm, и, в конце концов, это деталь реализации.

Разница между IQueryable и IEnumerable важна при работе с удаленными данными, но именно это и делает хранилище в первую очередь: оно скрывает тот факт, что вы имеете дело с хранилищем, которое может быть удаленным. Для приложения репозиторий - это просто локальная коллекция объектов.

Обновление Хранилище абстрагирует постоянный доступ, делает приложение отделенным от конкретной реализации постоянства и маскирует себя как простой набор. Это означает, что приложение не знает о Linq2Sql, Sql или типе используемой СУБД, если таковая имеется. Приложение отправляет / получает объекты из репо, в то время как репо фактически сохраняется или загружает объекты. Приложению не важно, как это делает репо.

Я считаю хранилище очень полезным шаблоном, и я использую его в каждом проекте, именно потому, что он отмечает границу между приложением (как местом, где проблемы и решения определяются и обрабатываются) и хранением / постоянством, где данные Сохраненный.

Answer 2

Вы можете сделать ваш репозиторий общим и получить из него значение режима.И убедитесь, что вы используете интерфейс (IItemRepository) для доступа к репозиториям на уровне менеджера, чтобы вы могли заменить свои репозитории другим методом доступа к данным, используя новую реализацию репозитория. Вот хороший пример e, как это сделать.