Вопрос передового опыта - работать прямо с Linq для классов SQL

Question

Возможно, это немного глупый вопрос, но я запутался из-за книги ASP.NET MVC, которую я сейчас читаю ...

Работая с Linq-To-SQL, кажется, что не рекомендуется передавать объекты Linq-SQL прямо в контроллер, но каждый объект должен сначала моделироваться отдельно, и это должно передаваться между контроллер и хранилище.

Скажите, у меня есть база продуктов. Linq-to-SQl создает для меня класс продуктов со свойствами Name, Price и Whatnotelse. Я мог бы передать это прямо из репозитория в контроллер и затем просмотреть, но вместо этого мне кажется, что я рекомендую использовать и третий класс, скажем Product_Entity, со свойствами Name, Price и т. Д. И передать его контроллеру.

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

Является ли этот подход действительно лучшей практикой? Или я все это неправильно понял? Если так, то почему плохо работать сразу с созданными linq-to-sql объектами? А как вы справляетесь с отношениями между объектами в y

Answer 1

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

• Ваши классы Linq to SQL предназначены для общения в области «данных».

• Ваши «данные»классы (те, с которыми у вас проблемы) предназначены для общения в домене «application».

Давайте рассмотрим пример.Предположим, в вашем приложении MVC вы хотели показать сетку информации о продуктах.Вы хотите увидеть их имя, цену (из таблицы продуктов) и страну их изготовления и название производителя (из таблицы производителей).Как бы вы назвали этот класс?Product_Manufacturer?Что если позже вы захотите добавить свойства из третьей таблицы, например, скидки на товары?Вместо того, чтобы думать об этих объектах в чисто области данных , подумайте о них в отношении вашего приложения .

Итак, вместо Product_Manufacturer, как насчет того, чтобы называть его ProductSummaryItem?Каждое свойство класса ProductSummaryItem будет отображаться 1: 1 с полем, отображаемым в вашей сетке в пользовательском интерфейсе.Ваш контроллер будет выполнять сопоставление информации в домене данных (Product, Manufacturer) с пользовательским классом, который вы создали в домене приложения (ProductSummaryItem).

Делая это, вы получаете удивительные преимущества:

1) Написание ваших взглядов становится действительно очень простым.Все, что вам нужно сделать, чтобы отобразить ваши данные - это циклически перебрать ProductSummaryItems и обернуть их в теги, и все готово.Это также позволяет для простой агрегации.Например, вы хотели добавить поле с именем ProductsSoldLastYear в ваш класс ProductSummaryItem.Вы можете сделать это очень просто в своих взглядах, потому что все это для них - другое свойство.

2) Поскольку представление является тривиальным и в контроллере присутствует логика отображения, становится намного проще проверить выход контроллера, поскольку он настроен на то, что будет видеть представление.

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

Этот шаблон называется Model View ViewModel (MVVM) и пользуется огромной популярностью как в MVC, так и в таких средах, как WPF.

Аргумент против MVVM заключается в том, что вам нужно несколько переопределить простые классы для операций CRUD.Полагаю, достаточно справедливо, но вы можете использовать такой инструмент, как automapper , чтобы помочь с такими вещами.Тем не менее, я думаю, вы довольно быстро обнаружите, что использование шаблона MVVM даже для CRUD приносит дивиденды, потому что, прежде чем вы это узнаете, даже с простыми классами, вы начнете хотеть иметь дополнительные поля, которые могут легко управлять вашими представлениями.