Переключение на LINQ
x
array([[[0, 1, 2],
[0, 1, 2],
[0, 2, 5]]])
x.shape
# (1, 3, 3)
Вы можете использовать Ellipsis (...) для выбора по всем крайним осям и вырезать первое значение из каждой строки с помощью 1:.
x[..., 1:]
array([[[1, 2],
[1, 2],
[2, 5]]])
x[..., 1:].shape
# (1, 3, 2)
5 ответов
Преимущество Linq перед Sql состоит в том, что он на самом деле не встраивает запросы в скомпилированный код - не совсем. Оператор Linq означает, что ваш .Net-код на самом деле имеет логику, необходимую для построения встроенного оператора Sql, а не необработанного Sql.
Действительно имеет смысл иметь .Net-код, который преобразуется непосредственно в Sql для выполнения, а не длинный список sprocs с соответствующей документацией. Путь Linq гораздо проще поддерживать и улучшать.
Я не думаю, что переключу существующий проект на Linq - на самом деле это замена всего уровня данных, и он может изменить способ доступа к этому уровню. сделано. Если вы не переключаетесь с очень похожей модели, цена будет слишком высока для любого потенциального выигрыша.
Линк к Sql '
Я согласен с вашей точкой зрения, это действительно кажется шагом назад ...
На самом деле, я бы, вероятно, отклонился от LINQ to SQL и посмотрел бы больше на LINQ to Entities, ваши сущности моделируют вашу концептуальную модель данных, и мне лично удобнее встраивать запросы в концептуальную модель в мой код. Фактическая физическая модель абстрагируется от вас структурой сущностей.
Эта ссылка (извините за каламбур) обсуждает LINQ to Entities и платформу сущностей: http://msdn.microsoft.com/en-us/ library / bb386992.aspx
Это интересная статья, в которой обсуждаются плюсы и минусы обоих подходов: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm
Редактировать Еще одна мысль, если вы не хочу ждать EF, взгляните на NHibernate, вы можете LINQ к этому тоже ... См. http://www.hookedonlinq.com/LINQToNHibernate.ashx
Вы должны думать о LINQ to SQL как об абстракции над написанием SQL непосредственно самостоятельно. Если вы можете обдумать это, тогда вы сделали шаг в правильном направлении. Вы также должны отказаться от некоторых давних убеждений, таких как скомпилированные sprocs всегда быстрее, и учетные записи SQL не должны иметь привилегий чтения / записи данных.
Я обнаружил, что можно начать постепенно перемещать существующие решения в сторону LINQ к SQL до тех пор, пока имеется четкий DAL, и вы просто меняете реализацию, не влияя на контракт, который он может иметь с потреблением кода. Списки ссылок являются легким кандидатом, так как они мало влияют, наборы данных только для чтения. Главное, что вам нужно помнить, если модернизация - это потенциальные неоднозначные имена классов, если вы уже вручную закодировали их для моделирования базы данных.
Учитывая ретроспективность внедрения LINQ to SQL в большое предприятие (начиная с CTP-дней), я бы сделал это снова в одно мгновение. Это не идеально, и есть проблемы, но есть огромные преимущества, особенно когда дело касается скорости разработки и удобства обслуживания. Это новая парадигма и, безусловно, безусловно, шаг вперед.
Существует реализация LINQ to SQL не только для баз данных SQL Server, поэтому разработчики, не относящиеся к SQL Server, также могут воспользоваться преимуществами этого эффективного ORM. Мы уже добавили поддержку LaodWith () уровня запросов и расширили обработку ошибок. Также мы планируем поддерживать все три модели наследования (TPH, TPT, TPC) и генерацию полей ключей. Вы можете найти список поддерживаемых баз данных здесь
Я не думаю, что об этом поскольку встроен SQL в вашем коде больше, чем встраивание сохраненного имени PROC в вашем коде. Чаще всего не изменение вашего PREC включает в себя изменения в ваш код в любом случае. Например, вам обычно нужно добавить новый параметр In / Out или обновить метод Getter / Setter для ссылки на новый столбец.
Что он делает, это удаляет много ног, работа над написанием в два раза больше, чтобы выровнять свойства и методы в вашем коде с помощью ProCES и столбцов в вашей БД.