Закрытие через 3 дня после раннего доступа, тут явно нечисто мне кажется. Или готовы были сразу закрываться, либо кому-то наобещали 3 короба, а потом к ним пришли с вопросами.
Недавно наткнулся на использование css-переменной isMobile по ширине 768(вроде). Чтоб потом каждую секунду из JS считывать эту переменную и добавить класс .col-md(да, в этой странице уже был bootstrap, который сам все это умеет на чистом css). Я прежде чем это вырезать, долго сидел в фейспалме.
А давайте интерфейс сюда впихивать не будем? мы про ORM говорили.
Табличная часть в документе это просто дополнительная возможность например впихнуть туда справочник товаров, в добавок к шапке документа. Я могу их сколько угодно сделать. .Записать() сразу записывает и шапку и табличную часть если она есть.
Так же и в EF. SaveChanges и все. Бегло посмотрел, табличные части напоминает доп связи, это все можно сделать в EF.(и нет, это не будет тысячи строк кода)
Если специально не посмотреть как формируются SQL операторы трассировкой , так никогда и не узнаешь.
Что ровно аналогично тому что есть в других ORM.
а не на эмуляцию SQL
Если мы не берем SimpleORM, например Dapper, но мы не пишем SQL. в EF используется LINQ, он же используется и просто в коллекциях. у LINQ есть 2 синтаксиса, 1 это SQL-подобный(я лично его не люблю), и второй это методы на коллекциях, db.Users.Where() и я просто пишу стандартный C#. можно даже не задумываться об SQL.
и язык запросов который заточен на метаданные
Вы про тот синтаксис что выше показывали(ВЫБРАТЬ, ИЗ, ГДЕ) ?
Если да, то мне в EF не нужно на такой почти-SQL переходить чтоб получить такой результат. Я просто работаю с объектами, и могу получить результат любого типа, а не весь документ.
Пример с переводом вашего SQL в LINQ-SQL синтаксис приводили. Но я бы предпочел через методы
Раньше был Access был в моде, где почемуто Не предлагали сразу наделать много кода. А делали когда уже задизайнили форму и таблички.
И где сейчас этот Access?
И его становится еще больше и больше
Без ORM его меньше не станет.
То что можно хранить с в XML как статическую информацию со связями, переезжает в код.
Hibernate вполне любит XML, И далее, у вас все равно по факту есть классы, только за вас их генерирует 1С.
В случае EF Code-First у нас код генерирует метаданные.
А сейчас ради полностью разделенного фронт, и бэкэнд и СУБД сразу все уезжает в Code first.
А что всем клиентам надо ставить тонкий клиент 1С чтоб Вам не пришлось разделять фронт и бэк?
Реальным клиентам нужен веб сайт, который будет работать, потом мобильное приложение и тп. а не формочки в 1С.(и чтоб они выглядели как им надо, а не как разработчики 1С решили)
Возьмите реальное веб-приложение, да тот же хабр или StackOverflow, почему он не на 1С написан тогда? раз там все так круто.
1С ограничена своей предметной областью, как бы то не было. Это ограничение дает ей преимущество внутри этой области, но вне нее, сразу начинаются проблемы.
Я не говорю что 1С плохая, да фичи, как я сказал прикольные, но вне 1С мира, они не нужны. мне не нужны визуальный редактор документов, когда мне нужно написать вебсайт по заказу услуг(возьмем например любую VDS), от этого все и идет. Я понимаю что все кажется гвоздем когда в руках молоток, но все же всему свое место.
Потому что в 1С Вы проектируете метаданные с нужными полями (класс Документ) с нужными реквизитами и если нужно табличными частями и уже потом платформа сама создает не только все таблицы но и оптимальные индексы под это.
В .Net тоже самое, только кодом. честно не вижу разницы(разделять там тоже можно).
Посмотрел я на ваши индексы, любые доп индексы надо так же ставить флаг Индексировать.
В .Net насколько помню можно делать похожее но только на уровне создаем класс, держим в уме таблицу которой он будет соотвествовать.
А зачем держать в голове это? Вы в 1С это делаете?
А так чтобы сделать класс , а Net. отразил бы это в несколько таблиц?
Есть разделение таблиц там.
Я вот не вижу глобально разницы, вот серьезно.
Создание метаданных в данном случае равноценно созданию классов. Это именно code-first по факту.
Одно дело когда вы написали класс Документ, который может управлять пятью таблицами не опускаясь на их уровень, а другое дело когда Вы эти таблицы тупо отображаете в классы, чтобы соединять их как запросы.
Пропустил этот момент. А почему у вас в 1С создание класса для хранения в БД это хорошо, а в .NET создание класса для того же это плохо?
1)Иногда EF сама может подсказать что запрос получился ужасным и его приходится вычислять на клиенте.
2)Узнать где проблема, у вас будет уже представление куда рыть, какой синтаксис повёл себя не так как Вы думали должен себя вести(в 90% случаев достаточно нажать F1 и все станет ясно)
3)На крайний случай всегда можно перейти в RAW запросы.
На практике я не сталкивался с тем чтоб EF вёл себя
Совет от меня: Если телефон сильно греется во время зарядки, попробуйте заряжать его в выключенном состоянии. В выключенном состоянии телефон "глупеет" и поддерживает только самые базовые протоколы зарядки, т.е., меньше греется.
У меня телефон поддерживает быструю зарядку в том числе в выключенном состоянии.
Но в настройках батареи можно выключить быструю зарядку.
Раньше пользовался, но сейчас перешёл на MobaXTerm.
Закрытие через 3 дня после раннего доступа, тут явно нечисто мне кажется. Или готовы были сразу закрываться, либо кому-то наобещали 3 короба, а потом к ним пришли с вопросами.
В любом случае, мне кажется это не нормально.
Это согласен, ChatGPT ещё этому помогает.
Недавно наткнулся на использование css-переменной isMobile по ширине 768(вроде). Чтоб потом каждую секунду из JS считывать эту переменную и добавить класс .col-md(да, в этой странице уже был bootstrap, который сам все это умеет на чистом css). Я прежде чем это вырезать, долго сидел в фейспалме.
А давайте интерфейс сюда впихивать не будем? мы про ORM говорили.
Так же и в EF. SaveChanges и все. Бегло посмотрел, табличные части напоминает доп связи, это все можно сделать в EF.(и нет, это не будет тысячи строк кода)
Что ровно аналогично тому что есть в других ORM.
Если мы не берем SimpleORM, например Dapper, но мы не пишем SQL. в EF используется LINQ, он же используется и просто в коллекциях. у LINQ есть 2 синтаксиса, 1 это SQL-подобный(я лично его не люблю), и второй это методы на коллекциях, db.Users.Where() и я просто пишу стандартный C#. можно даже не задумываться об SQL.
Вы про тот синтаксис что выше показывали(ВЫБРАТЬ, ИЗ, ГДЕ) ?
Если да, то мне в EF не нужно на такой почти-SQL переходить чтоб получить такой результат. Я просто работаю с объектами, и могу получить результат любого типа, а не весь документ.
Пример с переводом вашего SQL в LINQ-SQL синтаксис приводили. Но я бы предпочел через методы
Это вернет мне готовый словарь [Имя компании] => [Количество пользователей в ней].
Как видите на уровень SQL опускать не приходится. И такой же код используется при работе со списками и в целом любым итерируемым.
А что вам нужно? вы просили визуальный дизайнер БД, а не генератор приложений.
LLBLGen Pro, DevArt Entity Developer Entity Framework Visual Editor.
Есть и генераторы CRUD WebApi.
И где сейчас этот Access?
Без ORM его меньше не станет.
Hibernate вполне любит XML, И далее, у вас все равно по факту есть классы, только за вас их генерирует 1С.
В случае EF Code-First у нас код генерирует метаданные.
А что всем клиентам надо ставить тонкий клиент 1С чтоб Вам не пришлось разделять фронт и бэк?
Реальным клиентам нужен веб сайт, который будет работать, потом мобильное приложение и тп. а не формочки в 1С.(и чтоб они выглядели как им надо, а не как разработчики 1С решили)
Возьмите реальное веб-приложение, да тот же хабр или StackOverflow, почему он не на 1С написан тогда? раз там все так круто.
1С ограничена своей предметной областью, как бы то не было. Это ограничение дает ей преимущество внутри этой области, но вне нее, сразу начинаются проблемы.
Я не говорю что 1С плохая, да фичи, как я сказал прикольные, но вне 1С мира, они не нужны. мне не нужны визуальный редактор документов, когда мне нужно написать вебсайт по заказу услуг(возьмем например любую VDS), от этого все и идет. Я понимаю что все кажется гвоздем когда в руках молоток, но все же всему свое место.
Такое нужно только для расширенных вещей как раз.
или у вас в 1С табличные части сами себя объявляют?
Вы делаете тоже самое, только другим способом.
Кстати пример там не на разбитие на части, а наоборот, чтоб два класса были в одной таблице.
Это пишется один раз как бы.
У вас аргумент на уровне, кошмар, тут надо чуть больше написать. Это какое-то передергивание просто уже.
Я понимаю что в 1С это все спрятано за интерфейсом, но все же аналогичные действия нужно делать так или иначе.
Для EF есть дизайнеры.
Поймите, то что у вас чуть меньше одноразовых действий, не делает 1С прям офигенной, да на спорю, это неплохо. Но чтоб прям уберфича? нет.
Поэтому предлагаю закончить обсуждение одноразовых действий.
В .Net тоже самое, только кодом. честно не вижу разницы(разделять там тоже можно).
Посмотрел я на ваши индексы, любые доп индексы надо так же ставить флаг Индексировать.
А зачем держать в голове это? Вы в 1С это делаете?
Есть разделение таблиц там.
Я вот не вижу глобально разницы, вот серьезно.
Создание метаданных в данном случае равноценно созданию классов. Это именно code-first по факту.
Так а метаданные откуда взялись то?
Пропустил этот момент. А почему у вас в 1С создание класса для хранения в БД это хорошо, а в .NET создание класса для того же это плохо?
Простые ORM так сделают, у ORM с трекингом уже будет иначе
На SQL человек ровно так же напишет скорее всего тогда.
Я в таком случае готовлю дату которая нам нужна, и уже делаем стандартное Where(c=>c.CreatedDate >= minDate)
Ах да, scaffolding сторонних БД, вы серьёзно думаете что такое есть только в 1С?
Ну если я верно понимаю то основной аргумент за крутость 1С это то что у нее язык и IDE и БД связано воедино?
Естественно вещь в своём кружке может быть лучше.
Только вот в 1C вы создали таки этот тип, пусть и в интерфейсе, но сделали.
А давайте поставим .NET и 1C на равне?
Вы сейчас противопоставляете database first для .Net против code first(а конфигурация это именно code first по факту)
А вы можете в 1C запихнуть произвольную БД?
1)Иногда EF сама может подсказать что запрос получился ужасным и его приходится вычислять на клиенте.
2)Узнать где проблема, у вас будет уже представление куда рыть, какой синтаксис повёл себя не так как Вы думали должен себя вести(в 90% случаев достаточно нажать F1 и все станет ясно)
3)На крайний случай всегда можно перейти в RAW запросы.
На практике я не сталкивался с тем чтоб EF вёл себя
Разве во всех уважающих себя ORM нет логирования? где можно посмотреть что там делается.
А ещё советую узнать про ExecuteUpdate и ExecuteDelete.
Да, все верно, в России.
Как пользовался Spotify, так и продолжаю.
только для HTTP, для HTTPS же данных меньше.
По сути видно только домены(но не запросы/страницы внутри домена) которые вы посещаете.
Наверное, Direct Access Memory?
У меня телефон поддерживает быструю зарядку в том числе в выключенном состоянии.
Но в настройках батареи можно выключить быструю зарядку.