2010-06-16 1 views
0

Я «модернизирую» приложение MVC. Ранее DAL был частью Модели, как серия репозиториев (на основе имени сущности), используя стандартные запросы LINQ to SQL. Теперь это отдельный проект и создается с помощью PLINQO.Использовать шаблон хранилища при использовании данных, сгенерированных PLINQO?

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

Он работает нормально, это больше вопрос, чтобы опираться на ваш опыт, следует ли продолжать этот путь или пересобирать репозитории (используя PLINQO как DAL в файлах репозитория)?

Одним из преимуществ использования только созданного контекста данных PLINQO является то, что когда мне нужен доступ к БД, я просто делаю одну ссылку на контекст данных. В рамках шаблона репозитория мне приходилось ссылаться на каждый репозиторий, когда мне нужен доступ к данным, иногда приходится ссылаться на несколько репозиториев на одном контроллере.

Большое преимущество, которое я видел в репозиториях, было точно названо методами запросов (то есть FindAllProductsByCategoryId (int id) и т. Д.). С кодом PLINQO это _db.Product.ByCatId (int id) - что тоже неплохо.

Мне нравится обоим, но где он получает «лунь», когда запрос использует предикаты. Я могу свернуть это в метод запроса репозитория. Но в коде PLINQO это будет нечто вроде _db.Product.Where (x => x.CatId == 1 & & x.OrderId == 1); Я не уверен, что мне нравится иметь такой код в моих контроллерах.

Что вы думаете об этом?

ответ

2

- ЗАПРОС РАСШИРЕНИЕ -

Запрос Extensions PLINQO разработаны, чтобы быть в цепочке. Это должно помочь удержать вещи от слишком «гарри». ;)

// Лямбда
_db.Product.Where (х => x.CatId == 1 & & x.OrderId == 1);
// Запросные расширения
_db.Product.ByCatId (1) .ByOrderId (1);

// Еще более сложная Lambda
_db.Product.Where (х => (x.CatId == 1 || x.CatId == 3) & & x.OrderId = 1!);
// Запросные расширения
_db.Product.ByCatId (1, 3) .ByOrderId (ComparisonOperator.NotEqual, 1);

Кроме того, для действительно сложных запросов мы предлагаем добавить настраиваемые методы расширения к редактируемым (пассивно генерируемым) файлам расширения запроса. Это позволяет вам инкапсулировать вашу более продвинутую логику в одно место и сохранять код более чистым и расширенную логику более многоразовой.

http://docs.codesmithtools.com/display/PLINQO/Query+Extensions

- КАРТИНЫ -

Что касается рисунка, то мы обычно предлагаем вам новый вверх DataContext в использовании заявление каждый раз, когда вы хотите получить доступ к БД. LINQ to SQL (и, таким образом, PLINQO) используют шаблон «Единица работы» и хорошо работают в небольших контролируемых областях.

+0

Также ознакомьтесь с этим видео PLINQO http://www.youtube.com/watch?v=4CSXNWvFSwI –

+0

Это хороший момент. Я создавал пользовательские расширения запросов, в основном для сценариев объединения ... но определенно мог бы построить больше. Об использовании заявления ... вот что я делаю. Все мои контроллеры получаются из пользовательского базового контроллера. Поскольку все мои контроллеры требуют доступа к базе данных, я просто обновляю DataContext в базовом контроллере. Есть ли преимущество в эффективности использования заявления? Это означало бы, что мне нужно будет использовать оператор using почти для каждого действия на каждом контроллере. – Chaddeus

+0

Вот вам подробный ответ: http://stephenwalther.com/blog/archive/2008/08/20/asp-net-mvc-tip-34-dispose-of-your-datacontext-or-don -t.aspx :) – tdupont