Я бы сказал, что ваше представление класса Bus строго ограничено. Вариант, Модель, Производитель должны быть жесткими ссылками на классы, а не строками. Затем получить имя каждого.
Е.Г. с точки зрения Bus bus1 this.variant.GetName()
или из внешнего мира. bus1.GetVariant().name
Ограничивая вашу шину строками, в которых она хранится, вы вынуждены выполнять поиск даже внутри класса шины, который работает гораздо медленнее в масштабе, чем простая ссылка на память.
С точки зрения вашего API (хотя у меня нет примера), ваш единственный способ получить информацию об автобусе ограничен. Если состав шины изменяется (изменяются варианты, вводятся новые классы компонентов), это требует достойного переписывания этой функции, а если другие функции пишутся аналогично, то все эти два.
Это потребовало бы некоторого размышления, но общий подход к этому, который может динамически захватывать информацию на основе входных данных, облегчает добавление / удаление компонентов в дальнейшем. Это будет тем, на чем ваш интервьюер уделял основное внимание с точки зрения продвинутых технических и языковых навыков. Правильная реализация обобщений, делегатов и т. Д. Может значительно упростить дальнейшее обслуживание вашего API. (Извините, у меня нет примера)
Я бы не сказал, что ваш подход здесь обязательно плохой, хотя переменные-члены строки, вероятно, являются единственной серьезной проблемой.
Еще одно наблюдение; если Вы не используете введенные наборы данных, Вы могли бы также хотеть знать о Field<>
дополнительный метод:
var customerOrderIds = table.Rows.Cast<DataRow>()
.Where(x => x.Field<string>("CUSTOMER_ID") == customerId)
.Select(x => x.Field<string>("CUSTOMER_ORDER_ID"))
.Distinct();
Или использование синтаксиса запроса:
var customerOrderIds = (
from row in table.Rows.Cast<DataRow>()
where row.Field<string>("CUSTOMER_ID") == customerId
select row.Field<string>("CUSTOMER_ORDER_ID")
).Distinct();
Я не говорю, что это лучше или хуже - просто другой жизнеспособный вариант.
(На самом деле я не использую DataTable
очень, таким образом, YMMV)
Кажется хорошим мне - хотя я попытался бы использовать набор данных со строгим контролем типов, который заставляет запросы LINQ выглядеть еще более приятными.
Но да, LINQ является очень хорошей вещью - и LINQ к Объектам (и окружающие технологии для XML и DataSets) неправдоподобно предсказуем по сравнению с поставщиками LINQ из процесса. (Это менее сексуально, чем LINQ к SQL, но более широко применимый IMO.)
Запрос выглядит хорошо.
Я хотел бы указать на две мелочи.
Никакое цикличное выполнение
Система. Linq. Счетные методы управляют против IEnumerable (T) контрактом, который почти всегда означает цикличное выполнение - O (N) решения. Два последствия этого:
.Cast
.Cast работает отлично для DataTable. Строки (все те объекты-are-строки, таким образом бросок всегда успешно выполняется). Для неоднородных наборов, знать о.OfType () - который отфильтровывает любые объекты, которые не могут быть литыми.
Наконец, знайте, что запросы не выполняются, пока они не перечисляются! Можно вызвать перечисление foreach, ToList, ToArray, Во-первых, Единственный, и многое другое.
Вы не увлекаетесь вообще. Существуют фактические работы, опубликованные на LINQ к DataSets. Имение таких ясных, декларативных объектных запросов делает для намного более легкой надежности кода. Но необходимо помнить в то время, когда Вы фильтруете данные, все это было уже задержано. Можно хотеть рассмотреть добавление фильтрации к SQL для запроса DataSet.
Лично, так как таблица данных не имеет способности сделать выбор, отличный самостоятельно, я скажу, что это не все настолько плохо.
Я потенциально спросил бы хотя, если бы был какой-либо способ в конечном счете добраться до использования объектов, а не таблиц данных, поскольку я думаю, что для будущих разработчиков было бы легче понять.
LINQ просто пишет "код" переменной цикличного выполнения/временного файла для Вас. LINQ помогает Вам написать код быстрее (и более читаемый).
Вы - код, хорошо.
Соединение (с использованием ключевого слова join, но не ключевого слова from) использует словарь для совпадений и, таким образом, O (M + N)
.
Итак является группой, но не следующим:
from x in Xs
from y in Ys
.Where(o => o == x)
select new
{
x,
y
}
который равен O (M * N)
.