А, в этом смысле да. Хотя, если посмотреть на мок- и модульно-тестовые библиотеки, там это вполне основной подход. Да и внутренние DSL на C# тоже вполне неплохо пишутся, например, когда предметная область из каких-нибудь тарифов по-разному собираемых — очень читаемо и красиво получается :)
Жаль, что у вас негативный опыт :)
Честно говоря, я этот аспект (удобство оболочки в смысле сидения в ней как в постоянной основной рабочей среде) мало знаю, ибо (кто бы мог подумать :) ) не работаю в консоли постоянно.
Впрочем, коммиты в меркуриал делаю, и с русскими буквами все хорошо. Но вполне допускаю, что другие продвинутые оболочки гораздо дальше пошли в плане удобства копирования и т.п. вещей, о которых говорили выше.
Я скорее говорю именно про язык PS, а не интерфейс программы-консоли PS.
Конкретно, например: последнее большое мое дело с PS — это была автоматизация развертывания довольно большой программной системы на тестовые/живую среды, состоящие из многих машин.
На PS я в привычном мне объектно-ориентированном стиле описал структуру среды, структуру развертываемого решения. Конфигурации сред просто как DSL читаются (ну, по сути это и есть DSL). И это все чудо заработало чуть не с первого раза.
Что не так и удивительно, т.к. набирал я код большей части в PowerShellISE, где даже автозаполнение по полям и методам PS-объектов есть. И не только PS-объектов, а весь .NET Framework и любые кастомные классы тоже вызываются «как родные».
Так что, наверное, для тех, кто в консоли живет, PS и правда тормознутый, и вообще сама консоль у него, наверное, не айс.
А, например, для C#-ра, которому иной раз надо что-то там заавтоматизировать, PS — находка.
«Лучше cmd»… :) PowerShell — это настоящая объектная сценарная оболочка. По сути, почти «нормальный» язык программирования, недалеко (относительно, конечно) от C#. Сравнивать ее с текстовыми вообще не очень корректно, это другой уровень.
Можно такое сравнение привести — это как данные из plain text выдирать, или из JSON/XML.
Вроде конечно и из plain text выдрать можно, и некоторым даже нравится (можно регексом по нему шпарить), но, на мой скромный взгляд, для людей со структурным мышлением второе как-то пособнее будет.
Гпупости, это не шпионское оборудование для «скрытой» фиксации, там вполне очевидная камера и лампочка мигает. Шпионское — оно почти везде запрещено или ограничено, не только в ТС.
Так что с Гугл-Глазом можно общаться со всякими такими личностями, может оно и благотворно подействует. :)
Ну омонимов у нас предостаточно, одним больше — не страшно:) Просто «****шн» в русском языке звучит, на мой вкус, просто невыносимо. Так что «отражение», или можно транслитерировать как «рефлекция», что, кстати, этимологичнее, так как «-tion» — форма латинского «-tio», который «-цио».
Большое количество лишнего (причем довольно унылого) кода всех этих процедур, которого могло бы и вовсе не быть.
У нас, например, в новой части системы есть сборка с чистыми классами с моделью предметной области, и есть дополнительная сборка, описывающая отображение этого хозяйства в БД (.NET, POCO, EF Code First, DB Migrations).
При этом над схемой БД контроль полный, все изменения схемы, в т.ч. и при деплое новой версии кода и базы на live полностью автоматизированы.
И по вашим пунктам:
1. SQLя вообще нигде нет
2. Если я добавляю в объект поле, в вашем случае нужно еще добавить его в таблицу и в *-цать процедур, с ней работающих, да не забыть нигде, да при отсутствии компиляции… беда. А структура базы «изнутри» не так часто меняется (если эта БД — просто слой сохраняемости для данного приложения). А вот изменения со стороны функционала, т.е. со стороны объектов, гораздо более часты.
3. См п.1 — нет SQL — нет ошибок конкатенации. А просто DELETE без WHERE и процедуре точно так же напишете.
4. Единственное — согласен. Но для большинства реальный ситуаций это не самая актуальная проблема, и есть много других решений у нее.
А вот главный минус наличия чего-либо руками написанного на стороне БД — это лишнее место, куда может просочиться прикладная логика, что будет дополнительным усложнением и без того сложной программной системы.
Хех, обычно как раз русским в России фиолетово до укромовы (что плохо: знать и любить все наши языки пристало русскому человеку; там много красивого и ценного, и в белорусском, и в русинском, и во всевозможных говорах).
А вот русской половине Украины (у которой от засилья мовы сложилась аллергическая, зачастую неадекватно сильная, негативная реакция на этот красивый язык) — вот им часто хочется вставить что-то негативное.
И пока в общем и для русских, и для украинцев государстве Украина не будет абсолютного равноправия языков двух этих государствообразующих народностей — будет, увы, хохлосрач возникать в таких статьях, отнимая у умных наших людей силы на ненужное.
И вы, по идее, не можете написать конкретные приемочные тесты, если у вас нет точного знания «что в БД есть юзер Вася» и что «у юзера Васи строго один заказ».
Func не может при всем желании, ведь это просто ссылка на скомпилированный код, информация о том, что внутри «свойство А сравнивается со значением Б» уже утрачена (ну, сильно трасформирована, точнее) — на этапе компиляции проекта.
А Expression — это кусочек исходного дерева кода, в котором собственно ровно и написано, что «свойство А сравнивается со значением Б». Его можно легко преобразовать в Func, вызвав Compile, а можно и непосредственно как дерево обработать, например, преобразовать в SQL «поле А сравнить со значением Б».
Мне кажется, уже есть стандартный для вашего случая формат метаданных — Expressions. И с помощью PredicateBuilder легко получить такие «собираемые предикаты» и потом на этот полученный Expression можно скормит Entity Framework, LINQ, или даже для некоторого несложного подмножества написать свою реализацию репозитория, разбирающего выражение и делая запрос на основе него к произвольному хранилищу.
что большинство русских — ленивые пьяницы — это миф. большинство моих знакомых русские, и из них никто не подходит под такое определение. про китайцев не знаю, трудятся — молодцы, удачи им там.
Честно говоря, я этот аспект (удобство оболочки в смысле сидения в ней как в постоянной основной рабочей среде) мало знаю, ибо (кто бы мог подумать :) ) не работаю в консоли постоянно.
Впрочем, коммиты в меркуриал делаю, и с русскими буквами все хорошо. Но вполне допускаю, что другие продвинутые оболочки гораздо дальше пошли в плане удобства копирования и т.п. вещей, о которых говорили выше.
Я скорее говорю именно про язык PS, а не интерфейс программы-консоли PS.
Конкретно, например: последнее большое мое дело с PS — это была автоматизация развертывания довольно большой программной системы на тестовые/живую среды, состоящие из многих машин.
На PS я в привычном мне объектно-ориентированном стиле описал структуру среды, структуру развертываемого решения. Конфигурации сред просто как DSL читаются (ну, по сути это и есть DSL). И это все чудо заработало чуть не с первого раза.
Что не так и удивительно, т.к. набирал я код большей части в PowerShellISE, где даже автозаполнение по полям и методам PS-объектов есть. И не только PS-объектов, а весь .NET Framework и любые кастомные классы тоже вызываются «как родные».
Так что, наверное, для тех, кто в консоли живет, PS и правда тормознутый, и вообще сама консоль у него, наверное, не айс.
А, например, для C#-ра, которому иной раз надо что-то там заавтоматизировать, PS — находка.
И обобщенные типы в TypeScript — со следующей версии! И сразу нормальные типизированные реализации а-ля LINQ и прочее счастье :)
Можно такое сравнение привести — это как данные из plain text выдирать, или из JSON/XML.
Вроде конечно и из plain text выдрать можно, и некоторым даже нравится (можно регексом по нему шпарить), но, на мой скромный взгляд, для людей со структурным мышлением второе как-то пособнее будет.
Но для большинства классических сценариев аналог обобщенных типов — это именно то, что очень хочется видеть в TypeScript.
Так что с Гугл-Глазом можно общаться со всякими такими личностями, может оно и благотворно подействует. :)
У нас, например, в новой части системы есть сборка с чистыми классами с моделью предметной области, и есть дополнительная сборка, описывающая отображение этого хозяйства в БД (.NET, POCO, EF Code First, DB Migrations).
При этом над схемой БД контроль полный, все изменения схемы, в т.ч. и при деплое новой версии кода и базы на live полностью автоматизированы.
И по вашим пунктам:
1. SQLя вообще нигде нет
2. Если я добавляю в объект поле, в вашем случае нужно еще добавить его в таблицу и в *-цать процедур, с ней работающих, да не забыть нигде, да при отсутствии компиляции… беда. А структура базы «изнутри» не так часто меняется (если эта БД — просто слой сохраняемости для данного приложения). А вот изменения со стороны функционала, т.е. со стороны объектов, гораздо более часты.
3. См п.1 — нет SQL — нет ошибок конкатенации. А просто DELETE без WHERE и процедуре точно так же напишете.
4. Единственное — согласен. Но для большинства реальный ситуаций это не самая актуальная проблема, и есть много других решений у нее.
А вот главный минус наличия чего-либо руками написанного на стороне БД — это лишнее место, куда может просочиться прикладная логика, что будет дополнительным усложнением и без того сложной программной системы.
не говоря про две другие прекрасные у=оѵ и ю=іоѵ
А вот русской половине Украины (у которой от засилья мовы сложилась аллергическая, зачастую неадекватно сильная, негативная реакция на этот красивый язык) — вот им часто хочется вставить что-то негативное.
И пока в общем и для русских, и для украинцев государстве Украина не будет абсолютного равноправия языков двух этих государствообразующих народностей — будет, увы, хохлосрач возникать в таких статьях, отнимая у умных наших людей силы на ненужное.
А Expression — это кусочек исходного дерева кода, в котором собственно ровно и написано, что «свойство А сравнивается со значением Б». Его можно легко преобразовать в Func, вызвав Compile, а можно и непосредственно как дерево обработать, например, преобразовать в SQL «поле А сравнить со значением Б».
Поиграйтесь с ними побольше, они клёвые :)