Возвратить IQueryable <T> или не возвратить IQueryable <T>
Вы забыли установить параметр меток в confusion_matrix.
cm = confusion_matrix(y_test, y_pred, labels=brands)
3 ответа
Профессионалы; composability:
- вызывающие стороны могут добавить фильтры
- вызывающие стороны могут добавить подкачку страниц
- вызывающие стороны могут добавить сортировку
- и т.д.
Недостатки; нетестируемость:
- Ваш репозиторий больше не является правильно тестируемой единицей; Вы не можете полагаться на a: это работа, b: что это делает;
- вызывающая сторона могла добавить непереводимую функцию (т.е. никакое отображение TSQL; повреждения во времени выполнения)
- вызывающая сторона могла добавить фильтр/вид, который заставляет его работать как собака
- Так как вызывающие стороны ожидают
IQueryable<T>чтобы быть компонуемым, это исключает некомпонуемые реализации - или это вынуждает Вас записать Вашему собственному поставщику запроса для них - это означает, что Вы не можете оптимизировать / представляют DAL
Для устойчивости я взял к не представлению IQueryable<T> или Expression<...> на моих репозиториях. Это означает, что я знаю, как репозиторий ведет себя, и мои верхние уровни могут использовать насмешки без волнения "фактический репозиторий, поддерживает это?" (вызывающий интеграционные тесты).
Я все еще использую IQueryable<T> и т.д. в репозитории - но не по границе. Я отправил еще некоторые мысли об этой теме здесь. Столь же легко поместить параметры подкачки страниц на интерфейс репозитория. Можно даже использовать дополнительные методы (в интерфейсе) для добавления дополнительных параметров подкачки страниц, так, чтобы реальные классы только имели 1 метод для реализации, но может быть 2 или 3 перегрузки, доступные вызывающей стороне.
Как упомянуто предыдущим ответом, выставляя IQueryable предоставляет доступ к вызывающим сторонам для проигрывания с самим IQueryable, который является, или это может стать опасным.
Инкапсуляция первой ответственности бизнес-логики должна поддержать целостность Вашей базы данных.
Вы можете продолжить выставлять IList и можете быть изменением Ваши параметры как после, это - то, как мы делаем...
public interface ILocationRepository
{
IList<Location> FindAll(int start, int size);
IList<Location> FindForState(State state, int start, int size);
IList<Location> FindForPostCode(string postCode, int start, int size);
}
если размер ==-1 затем возврат все...
Альтернативный путь...
Если Вы все еще хотите возвратить IQueryable, то можно возвратить IQueryable Списка в функциях.. например...
public class MyRepository
{
IQueryable<Location> FindAll()
{
List<Location> myLocations = ....;
return myLocations.AsQueryable<Location>;
// here Query can only be applied on this
// subset, not directly to the database
}
}
Первый метод имеет преимущество перед памятью, потому что Вы возвратите меньше данных вместо всех.
Я рекомендую использовать IEnumerable вместо IList, с ним у Вас будет больше гибкости.
Таким образом, Вы сможете добраться от дб только что часть данных который Вы действительно собирающийся использование без дополнительной работы, сделанной в Вашем репозитории.
Образец:
// Repository
public interface IRepository
{
IEnumerable<Location> GetLocations();
}
// Controller
public ActionResult Locations(int? page)
{
return View(repository.GetLocations().AsPagination(page ?? 1, 10);
}
Который является супер чистым и простым.