возврат IList <T> по сравнению с Массивом в C#?
Да, это возможно, но вы должны отправить контекстную информацию в шаблон с такими же именами.
см. Пример ниже
def some_view(request):
context = {'links': links_queryset}
return render(request, 'nextPage.html', context)
11 ответов
Я думаю, что он, возможно, подумал, поскольку свойство длины массива является неизменным, тогда каким-то образом массивы на более неизменны, чем IList, или, может быть, он использовал неправильное слово и поменял бетон на неизменяемый. Кто знает, но это странный ответ.
Я думаю, что при возврате List есть что-то, слегка подразумеваемое, что его можно изменить или что он может измениться, в то время как возвращение массива не означает, что это так много.
Например, Если у вас была объектная модель поверх хранилища, и у вас был метод, такой как GetCars (), который возвращал List, и младший программист видел автомобили. Добавить (Car c) ... Вы думаете, он был совершенно безумным для мыслящих автомобилей. Добавить (новая машина ()) может добавить машину в хранилище? Массивы по своей природе просто более явные.
Я думаю, что использование List более уместно в свойствах, как Page.Controls.Add
Я предпочитаю возвращать массивы чаще, чем List по нескольким причинам.
Привычка. Коллекции в 1.0 / 1.1 SUCKED
Я предпочитаю, чтобы мои методы возвращали самый простой и легкий объект, который они могут. Если мне нужно сделать Array a List, это тривиально.
Их можно использовать в .net 1.1, и это сокращает поверхность рефакторинга, если мне когда-либо понадобится поддержка более старых версий среды выполнения, я могу повторно использовать по крайней мере некоторые из них. мой код или применить идентичную объектную модель.
Я всегда предпочитаю ReadOnlyCollection . Все преимущества списка, но только для чтения.
Один момент, который он мог бы иметь в виду, заключается в том, что IList включает методы Insert, Remove и Add, так что саму коллекцию можно изменить. T [], с другой стороны, не может иметь добавленных элементов.
Я должен добавить, что FxCop рекомендует вместо этого возвращать ReadOnlyCollection. Индексатор доступен только для чтения, поэтому вы не можете изменять элементы,
Кто бы он ни был, он на 100% не прав по этой теме. Массивы очень изменчивы. На самом деле это одна из причин не возвращать массив. Невозможно помешать вызывающей стороне изменить элементы массива так, как им будет угодно.
Единственный способ неизменности Arrray - это его длина. После выделения массива его длина не может быть изменена. Даже такие API, как Array.Resize, на самом деле не меняют размер массива, они просто выделяют новый, копируют содержимое и возвращают новый массив (в данном случае, по ссылке).
Однако я согласен, что есть много случаев в котором лучше вернуть неизменные данные. Основным из них является то, что он позволяет вам возвращать ссылку на внутреннюю коллекцию класса, не делая полную копию и в то же время не давая вызывающей стороне связываться с вашим внутренним состоянием. Большинство изменчивых коллекций не могут дать такие гарантии.
В принципе он прав, но он не знает, как правильно его практиковать ...
Обычно мы предпочитаем неизменяемые типы над изменчивыми.
Это правильно. С неизменными типами лучше работать с
. Массивы являются неизменяемыми. IList нет.
Это не правильно. Ни один из них не является неизменным.
Если вы хотите вернуть коллекцию, которая является неизменной, верните IEnumerable или ReadOnlyCollection (используя Перечислите метод ). Тем не менее, они не защищают объекты, если они сами не являются неизменными. Даже если вы можете только читать из коллекций, вы все равно можете изменять данные в каждом объекте, если они позволяют это.
Кроме того, вы должны учитывать «принадлежность» коллекции, которую вы возвращаете. Если вы создаете массив с единственной целью его возвращения, то нет никаких оснований не предоставлять ему полный контроль.
Я тоже этого не понимаю. Массивы очень изменчивы, за исключением их размера. Отдельные элементы все еще могут быть изменены. Возможно, он имел в виду, что массивы являются типами значений, а списки - ссылочными типами. Я не знаю.
В любом случае, вам, вероятно, стоит взглянуть на мнение Эрика Липперта по этому вопросу. Могу также предоставить вам боеприпасы для обсуждения.
Причина использования интерфейса в качестве типа возвращаемого значения поверх самого фактического типа заключается в том, чтобы скрыть внутреннюю реализацию от вызывающей стороны. Это позволяет реализации изменять фактический тип без каких-либо повторений для остальной части приложения.
Нет смысла копировать внутренне используемую коллекцию в массив для внешнего использования ни по какой другой причине, кроме как изменяемой или неизменной.
Отдельные вопросы: - вернуть список строго типизированных данных или нет. IList или IList. Использование строго типизированных данных всегда предпочтительнее. изменчивый или неизменный. ICollection, IList или IEnumerator Return with what you want to allow to the data. For a readonly list return only a IEnumerator. If the caller is allowed to modify the collection use ICollection or IList.
Возможно, он имел в виду размер массива как «неизменный»? По сути, вы объявляете размер один раз, и вы застряли с ним. Со списками вы всегда можете использовать «Добавить».
Я предполагаю , что , если вы уверены в размере списка, возможно, массив немного быстрее?
Хорошо. IList изменчив в том смысле, что вы можете добавлять и удалять элементы, а не просто изменять элементы, которые уже есть. Массив позволяет связываться с отдельными элементами, но определенный индекс никогда не станет полностью недействительным. Существует множество причин, по которым предпочтение следует отдавать неизменности - например, это делает площадь поверхности для случайного повреждения данных намного меньше.
По сути, он говорит: «Мы предпочитаем структуры, которые нельзя легко изменить во время выполнения, потому что мы считаем, что они менее уязвимы для ошибок». Верно ли это в этом случае - другой вопрос.