□ Из действия контроллера можно обратиться к представлению, находящемуся в любой из директорий, указав полный путь к представлению. Аналогично, представление может использовать частичные представления, размещенные в разных директориях, с указанием полного пути к ним, однако такой подход приводит к путанице, и мы настоятельно рекомендуем группировать представления, относящиеся к одному контроллеру, в одну директорию.
□ В случае, когда нескольким контроллерам может понадобиться использовать одну и ту же разметку представления, стоит подумать о будущем развитии проекта и выбрать один из двух путей.
□ Разметка всегда будет одинакова для обоих контроллеров — в этом случае представление следует разместить в директории Shared.
□ Разметка может в будущем различаться — в этом случае общую разметку следует вынести в файл частичного представления и поместить в директорию Shared, а для каждого из контроллеров создать собственное представление. Не стоит смущаться, если в начале разработки проекта каждое из представлений будет содержать только ссылку на общее частичное представление — в будущем будет значительно проще модифицировать представления для контроллеров, если избежать слияния разметки в самом начале развития проекта.
□ Директория Views предназначена только для файлов представлений, обрабатываемых механизмом генерации представлений, статические файлы, используемые на страницах (js, .css, изображения), следует размещать в других директориях. Например, в шаблонном проекте MVC Application, создаваемом Visual Studio, предлагается использовать для статических файлов директорию Content, а для скриптов .js директорию Scripts. Здесь уже выбор может определяться полностью вашим вкусом. Неплохой идеей может быть создание директории Content с вложенной структурой директорий, повторяющей структуру директории Views, где статические файлы будут размещены по тому же принципу, что и в директории Views. Возможно, что вам будет удобнее создать иную структуру директорий и группировать статические файлы не по принадлежности к представлениям, а по расположению звезд на небосклоне или какой-либо другой логике.
Данные для отображения и ViewData
В главе 1 кратко был описан механизм передачи данных от контроллера представлению. Поскольку основной задачей представления является отображение данных, мы подробно остановимся на этой теме.
ViewData
— это класс типа viewDataDictionary
, из названия типа которого очевидно, что ViewData
представляет собой коллекцию типа ключ-значения, называемую словарем.
public class ViewDataDictionary : IDictionary {}
Поскольку ViewData
является коллекцией доступных по строковому ключу объектов, в ней может быть сохранено произвольное количество объектов разных типов.
public ActionResult ViewDataDemo()
{
ViewData.Add("Hello", "World");
ViewData["Date"] = DateTime.Now;
return View();
}
Объекты, содержащиеся в коллекции ViewData
, в свою очередь, могут быть использованы в разметке представления.
Строгая типизация данных представления
Работа с произвольным набором элементов удобна, когда набор данных, отображаемых представлением, меняется в процессе развития проекта. Однако в случаях, когда все данные представления могут быть описаны одним классом, значительно удобнее использовать строго типизированные представления. Для этого коллекция ViewData
предоставляет свойство ViewData.Model
и возможность строгой типизации представления путем наследования самого класса представления от класса ViewPage.
В листинге 5.4 представлена разметка строго типизированного представления.
Листинг 5.4. Представление ViewDataModelStronglyTyped.aspx
ViewDataModelStronglyTyped
ViewDataModelStronglyTyped
Fields
CompanyName:
ContactName:
ContactTitle:
Address:
С точки зрения контроллера, для работы со строго типизированным представлением достаточно присвоить объект свойству ViewData.Model либо передать объект в качестве параметра методу View ().
public ActionResult ViewDataModelStronglyTyped()
{
NorthwindDatabase db = new NorthwindDatabase();
return View(db.GetCustomers().First());
}
В случае нестрого типизированного представления объект также может быть передан в свойство ViewData.Model
, однако это не имеет практической пользы, поскольку на стороне представления все равно придется выполнять приведение типов для свойств этого объекта.
Преимущества строго типизированного представления очевидны — поддержка подсказки IntelliSense при разработке представлений в Visual Studio, возможность генерации заготовок представлений средствами Visual Studio, как это было выполнено для представления, приведенного в листинге 5.4.
Читать дальше
Конец ознакомительного отрывка
Купить книгу