ASP MVC: сервисы должны возвратить IQueryable's?
Что Вы думаете? Ваш ДАО должен возвратить IQueryable для использования его в контроллерах?
4 ответа
Операторы Boost могут быть именно такими, какие вам нужны. Они выведут большинство ваших операторов на основе нескольких фундаментальных.
Что C++ не обеспечивает это автоматически имеет смысл, так как можно дать совершенно другие значения < и >, например (хотя это часто было бы плохой идеей).
-121--4648371-Я наткнулся на этот пост, исследуя тот же вопрос. Я еще не пришел к каким-либо выводам о лучшем инструменте или подходе, но один из инструментов, с которым я сталкивался, который до сих пор не упоминался в других ответах, это dbdeploy . Мне было бы интересно прочитать любые сравнения этих инструментов.
Некоторые другие соответствующие ресурсы: Martin Fowler и Pramod Sadalage несколько постой пост на Evolutionary Database Design , и книга Refactoring Database: Evolutionary Database Design от Sadalage и Scot Ambler.
-121--805981-На данный момент это звучит привлекательно, но на самом деле не .
Нет. Ваши контроллеры вообще не должны обрабатывать сложную логику. Держите их стройными; Модель (не DAO) должна вернуть Контроллеру все, что ему нужно передать в представление.
Просмотр запросов (или даже запросов) в классе контроллера - это то, что я считаю запахом кода.
Мне нравится передавать IQueryable в свои контроллеры, потому что мне не нужно создавать неубедительные методы разбиения по страницам и сортировки в каждом отдельном методе и интерфейсе DAO на протяжении всего срока службы моего разработка приложений.
GetCustomersByLastname( string lastname )
Быстро становится
GetCustomersByLastname( string lastname, string sortcolumn, int pagesize, int page )
Снова и снова, снова и снова. Блек!
С помощью IQueryable вы можете реализовать разбиение по страницам и сортировку ортогональными способами, например, используя преимущества проекта IPagedList. Возврат IQueryable также дает вам легкий доступ к общему объекту .Count () без дальнейшего искажения вашего уровня данных.
Аргумент @Robert о том, что IQueryable равняется толстым контроллерам, очень шаткий. Контроллер Fat был бы похож на раздутые страницы .aspx.cs прошлого. Если все, что вы делаете, подключаетесь к вашему DAL, а затем отправляете результаты, вы не получаете «жирности» от вашей техники запросов, вы получаете это, запихивая много логики внутри одного класса. Вы не получите Fat Controller из-за ваших методов доступа к данным, если вы не начнете внутри себя ведение журналов, уведомлений и других ортогональных проблем.
public ActionResult Detail( string searchTerm )
{
var model = MyDAL.MyObjects( searchTerm );
}
vs:
public ActionResult Detail( string searchTerm )
{
var model = MyDAL.MyObjects.Where( x => x.Name == searchTerm );
}
Я не вижу существенной разницы.
Ответ @Mark Seemann столь же шаткий. Конечно, вы можете изменить весь свой уровень данных в середине проекта, но это будет сложной катастрофой, независимо от того, насколько вы абстрагированы. В качестве примера он использует переход с Linq2Sql на хранилище таблиц Windows Azure.RDBMS в хранилище ключей / значений? И проблема в вашей реализации репозитория? Переход от РСУБД к хранилищу ключей / значений будет неким безумием, которое, несмотря ни на что, будет ужасным.
Марк также упоминает в своей аргументации предметно-ориентированный дизайн. Это тип системы вашего здания. Достаточно ли сценариев «домена», а не чисто CRUD-сценариев, которые делают этот подход ценным? Если нет, то зачем?
Использование LINQ и интерфейса IQueryable в любом случае избавляет вас от проблем, связанных с переключением уровней данных. Если вы переключаетесь между ORM, которые поддерживают LINQ и IQueryableProvider (я думаю, это имя), то только нижестоящий код заботится об этом изменении. Теперь ваши контроллеры останутся такими же, переключаясь между большинством ORM на рынке.
Если вы следуете парадигме "толстые модели, худые контроллеры", то нет.
См. этот пост на Толстый контроллер анти-паттерн.