Которые делают Вы предпочитаете для интерфейсов: T [], IEnumerable <T>, IList <T>, или другой?
Я думаю, что это - то, что Вы хотите.
select id, max(v_id), field1, field2 from table group by id
результаты я добираюсь от этого,
1, 2, textb, text2
2, 3, текст, Редактирование text5
: я воссоздал таблицу, и вставьте те же данные с идентификатором version_id, являющийся составным первичным ключом. Это дало ответ, который я предоставил ранее. Это было также в MySQL.
8 ответов
Я предпочитаю IEnumerable . Любой другой из предложенных интерфейсов дает возможность потребителю изменять базовую коллекцию. Это почти наверняка не то, что вы хотите сделать, поскольку это позволяет потребителям незаметно изменять внутреннюю коллекцию.
ИМХО, еще один хороший вариант - ReadOnlyCollection . Он позволяет использовать все забавные свойства .Count и Indexer и недвусмысленно говорит потребителю, что «вы не можете изменять мои данные».
Я не возвращаю массивы - они действительно ужасный тип возвращаемого значения для использования при создании API - если вам действительно нужна изменяемая последовательность, используйте IList или ICollection интерфейс или вместо этого вернуть конкретную Collection .
Также я бы посоветовал вам прочитать Массивы, считающиеся несколько вредными Эриком Липперт:
Я получил моральный вопрос от автора. учебников по языкам программирования на днях спрашивая мое мнение о будь то начинающие программисты следует научить пользоваться массивами.
Вместо того, чтобы отвечать на этот вопрос вопрос, я дал ему длинный список моих мнения о массивах, как я использую массивы, как мы ожидаем, что массивы будут используется в будущем и так далее. Эта получается немного длинновато, но, как и Паскаль, я не успел сделать короче.
Позвольте мне начать с того, что вы определенно не следует использовать массивы и затем более философски рассуждайте о будущее современного программирования и роль массива в грядущем мире.
Для индексированных коллекций свойств (и индексы имеют необходимое семантическое значение) следует использовать ReadOnlyCollection (только для чтения) или IList (чтение / запись). Он самый гибкий и выразительный. Для неиндексированных коллекций используйте IEnumerable (только чтение) или ICollection (чтение / запись).
Параметры метода должны использовать IEnumerable < T> , если они 1) не нуждаются в добавлении / удалении элементов из коллекции ( ICollection ) или 2) требуют индексов для необходимых семантических целей ( IList ). Если метод может извлечь выгоду из доступности индексации (например, процедуры сортировки), он всегда может использовать как IList или .
Я бы предпочел IEnumerable, так как это самый высокий уровень интерфейсов, дающий конечному пользователю возможность выполнять преобразование по своему желанию. Несмотря на то, что это может предоставить пользователю минимальную функциональность для начала (в основном, только перечисление), этого все равно будет достаточно для удовлетворения практически любых потребностей, особенно с помощью методов расширения, ToArray (), ToList () и т. Д.
Я думаю об этом с точки зрения написания наиболее полезного из возможных кодов: кода, который может делать больше.
В этих терминах, это означает, что мне нравится принимать самый слабый , который можно использовать в качестве аргументов метода, потому что это делает мой код более полезным. В данном случае это IEnumerable . Есть массив? Можете назвать мой метод. Есть список? Можете назвать мой метод. Есть блок итератора? Вы уловили идею.
Это также означает, что мне нравятся мои методы, которые возвращают самый сильный интерфейс, который удобен, так что код, который полагается на метод, может легко делать больше. В данном случае это будет IList . Обратите внимание: это не означает, что я создам список только для того, чтобы вернуть его. Это просто означает, что если у меня уже есть что-то, реализующее IList , я могу его использовать.
Обратите внимание, что я немного нестандартен в отношении возвращаемых типов. Более типичный подход - также возвращать более слабые типы из методов, чтобы избежать привязки к конкретной реализации.
IEnumerable
Но в качестве возвращаемого типа для типичного уровня доступа к данным свойство Count часто бывает полезным, и я бы предпочел возвращать ICollection
Это также указывает вызывающей стороне, что коллекция действительно была материализована. Таким образом, вызывающая сторона может перебирать возвращенную коллекцию, не получая исключений из уровня доступа к данным. Это может быть важно. Например, служба может генерировать поток (например, SOAP) из возвращенной коллекции. Это может быть неудобно, если исключение выбрасывается из уровня доступа к данным при генерации потока из-за итерации с отложенной оценкой,
Поскольку методы расширения Linq были добавлены в IEnumerable
Я бы не стал использовать массив, это тип, который допускает модификацию, но не имеет добавления / удаления ... что-то вроде худшего из всех. Если я хочу разрешить модификации, я бы использовал тип, поддерживающий добавление / удаление.
Если вы хотите предотвратить модификации, вы уже обертываете его / копируете, поэтому я не вижу, что не так с IEnumerable или ReadOnlyCollection. Я бы выбрал более позднее ... кое-что, что мне не нравится в IEnumerable, так это то, что он ленив по своей природе, но когда вы используете предварительно загруженные данные только для их обертывания, вызывающий код, который работает с ним, имеет тенденцию предполагать предварительно загруженные данные. загруженные данные или лишние "ненужные" строки :( ... которые могут привести к некрасивым результатам при изменении.