ASP.Net Mvc - допустимо ли для View вызывать функции, которые могут вызывать получение данных? - PullRequest
8 голосов
/ 06 января 2009

В настоящее время я играю с фреймворком Asp.Net mvc и люблю его по сравнению с классическим способом asp.net. Одна вещь, которую я обсуждаю, это то, допустимо ли для View вызывать (косвенно) доступ к базе данных?

Например, я использую контроллер, чтобы заполнить пользовательский класс данных всей информацией, которая, по моему мнению, должна выполнять свое представление для представления, однако, поскольку я передаю объекты в представление, это также может вызвать чтение базы данных. 1003 *

Быстрый псевдо-пример.

public interface IProduct
{
    /* Some Members */

    /* Some Methods */
    decimal GetDiscount();
}

public class Product : IProduct
{
    public decimal GetDiscount(){ ... /* causes database access */ }
}

Если представление имеет доступ к классу Product (ему передается объект IProduct), оно может вызвать GetDiscount () и вызвать доступ к базе данных.

Я думаю о способах предотвратить это. В настоящее время я рассматриваю только наследование нескольких интерфейсов для класса Product. Вместо реализации только IProduct теперь будут реализованы IProduct и IProductView. IProductView будет перечислять членов класса, IProduct будет содержать вызовы методов, которые могут вызвать доступ к базе данных.

«Представление» будет знать только об интерфейсе IProductView класса и не сможет вызывать методы, вызывающие доступ к данным.

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

Итак, мои вопросы:

  • Есть ли лучшие практики по этому вопросу?
  • Как другие люди, использующие MVC, не допускают, чтобы View был непослушным и делал с объектами больше, чем следовало бы?

Ответы [ 5 ]

3 голосов
/ 06 января 2009

Ваш взгляд на самом деле не вызывает доступа к данным. Представление просто вызывает метод GetDiscount () в интерфейсе модели. Это модель , которая вызывает доступ к данным. Действительно, вы можете создать другую реализацию IProduct, которая не будет вызывать доступ к данным, но при этом не будет никаких изменений в представлении.

Объекты модели, которые выполняют отложенную загрузку, неизменно вызывают доступ к данным, когда представление пытается извлечь данные для отображения.

Все ли в порядке, зависит от личного вкуса и предпочтений.

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

1 голос
/ 06 января 2009

Если вы сохраняете свои доменные объекты "постоянными невежественными", то у вас нет этой проблемы. То есть, вместо того, чтобы иметь getDiscount внутри вашего класса Product, почему бы просто не иметь простое свойство с именем Discount? Это будет установлено вашим ORM при загрузке экземпляра класса Product из базы данных.

1 голос
/ 06 января 2009

Единственное, что я обсуждаю, это то, допустимо ли для View создание (косвенно) доступа к базе данных?

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

0 голосов
/ 06 января 2009

Я создал сайт в MonoRail до того, что иногда есть методы, которые запускают доступ к данным из представления. Я стараюсь избегать этого, потому что когда он терпит неудачу, он может потерпеть неудачу необычными и нефиксированными способами (например, я не могу по-настоящему попробовать / поймать в шаблоне NVelocity). Это не конец света - я годами писал хорошо абстрагированные PHP-сайты, которые обращались к базе данных из представления, и они все еще работают достаточно хорошо, потому что большую часть времени, если что-то взрывается, вы просто перенаправляете на " Что-то не сработало », в любом случае страница типа ошибки.

Но да, я стараюсь избегать этого. В более широком смысле моя модель предметной области обычно не просачивается полностью в представление. Вместо этого представление рендерит Document объекты, которые бесстыдно являются просто типизированными дампами данных, со всем предварительно отформатированным, взбитым, раздавленным и протертым до такой степени, что представление просто должно выплевывать некоторые строки с некоторыми циклами и если / else, преобразуйте число «4» в изображения 4 звезды и т. д. Этот документ обычно возвращается веб-службой, которая находится перед красивой моделью домена, или это просто простая структура, которая создается в контроллере и прошло как часть ViewData. Если объект домена используется напрямую, то он обычно ничего не делает для явного запуска доступа к данным; это обрабатывается хранилищем, похожим на коллекцию, к которому у представления нет доступа, и к объектам домена обычно тоже нет доступа.

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

0 голосов
/ 06 января 2009

Модель не должна иметь методы («действия»), которые состоят из доступа к данным. Это забота DAL. У вас может быть свойство процента скидки, сохраненное в классе продукта, и метод GetDiscount возвращает простой расчет, такой как Price * (100 - discountPercent) или что-то вроде этого.

Я отключаю свои бизнес-объекты (продукт в вашем примере) от доступа к данным. Это проблема хранилища (в моем случае).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...