Я бы назвал это — синтаксическим сахаром, чтобы .net разработчики быстрее осваивались в js среде.
Как ни крути, тяжело переходить с C# на js- по себе знаю- этот переход- огромный шок для человека.
Когда разработчик уже освоится, тогда он сам углубится и изучит.
Есть еще кстати одно решение, если вы дебажитесь из студии- Intellitrace можно включить настройку логировать события ado.net.
Оно конечно не подходит не для .net проектов, но EF я именно так дебажил, когда не хватало прав на сервере.
SQL Server Profiler — не то, чтобы сильно не удобный… он просто не для EF
Он рассчитан на просмотр того, что происходит на SQL Server, а не того, что выходит с EF.
Лично меня больше всего в sql server profile досаждало- необходимость иметь права, куда большие чем нужные приложению.
Т.е. под стандартной учеткой на чтение данных использование профилировщика- не получится.
Да уже одно требование по лицензии- сразу минус. Не потому что бедные мы, а потому что на распробовать не хватит.
Hello World- писать всегда легко, а дальше обычно начинаются подводные грабли.
Rest/Soap вместе на базе одного сервиса- как минимум странно, как максимум плохо. Это два разных принципа построения Api. Один — манипуляции с ресурсов, второй по сути Remote Procedure Call. Если они мешаются, значит что-то явно не так.
Хостинг на Linux- вообще-то Asp.Net WebApi тоже прекрастно хостится там, не совсем из коробки, но можно.
Я ни в коем случаи не против этого framework, и даже его пробовал… просто ваши аргументы- не аргументы.
Абсолютно поддерживаю. Если человек учит не js, а .net все таки то ему надо работать с базой, с orm. А главное по началу тяжело будет человеку объяснить что такое stabs, mocks, fakes и так далее.
Расскажу историю, которую увидел во время оформления стажером в microsoft.
Оформление в понедельник всех стажеров, которые приходят в эту неделю. Нас было человек 250, стажеры ms, msr и не только разработчики но и nba. Это четко построенный конвеер.
Десятки компов для заполнения анкет, несколько человек с фотокамерам, делать фото на пропуск. Десятки столов с сумками, которые выдают всем стажерам. Везде указатели по следующим этапам. Куча асистентов отвечающих на вопросы.
И так летом почти каждую неделю.
И тут ты понимаешь, что когда в компании 50000+ сотрудников, то по другому ни как. С текучкой хотя бы 10% это надо набирать 5000 человек в год.
Уверен что в Google такая же картина.
А уж из этих десятков тысяч человек уходящих каждый год из microsoft-google-apple в стартапы точно кто-нибудь подастся.
Пару мелочей от зануды.
1- protected RestClient _client = new RestClient(«translate.yandex.net/api/v1.5/tr/»); — обычно считается плохим тоном, тк строка забита жестко.
2- www.nuget.org/packages?q=yandex выложите сюда. Основная проблема на моей памяти со всеми библиотеками, что их найти тяжело. Nuget- это то место от куда все пакеты и качают и начинают их искать.
Переформулирую вопрос более развернуто.
1-Мое Вам уважение, что Вы это провернули! Задачка не является тривиальной и до нее еще додуматься надо.
2-Почему так важна возможность «хочется, не покидая Management Studio, изменять поведение своих процедур» Вы ведь сами сказали- «иногда требуется».
При этом единственным преимуществом является- отсутствие необходимости перекомпилировать и обновлять clr сборку… При том, что сразу всплывет куча проблема (Ради иногда нужно писать код не на 2 языках, а на 3… а там уже куча всяких тонких моментов всплывет, о которых не рассказывают евангелисты на презентациях)
Если задача одноразовая — то можно и просто на C# через какой-нибудь ef написать маленькую программку, сделать и выкинуть ее.
Если многоразовая-типовая- то вряд ли вам будет нужно менять код. Написать на .net clr без всяких dlr и пусть работает.
Если многоразовая не типовая- то тогда действительно наверное использование более мощного языка программирование оправдано.
питоновскую консоль и в sl вставляли и в веб контролы и еще куда-то… в итоге дальше примеров, не слышно что это кто-то использовал по настоящему.
P.s. в 2012 студии большой кусок management studio встроен уже в ide. Я лично не открываю management studio довольно давно за ненадобностью.
С .net и powershell и так все понятно давным давно.
Сейчас скорее какой-нибудь SignalR для чатов на .net модно (без звука, видео и файлов)
Как ни крути, тяжело переходить с C# на js- по себе знаю- этот переход- огромный шок для человека.
Когда разработчик уже освоится, тогда он сам углубится и изучит.
Оно конечно не подходит не для .net проектов, но EF я именно так дебажил, когда не хватало прав на сервере.
Он рассчитан на просмотр того, что происходит на SQL Server, а не того, что выходит с EF.
Лично меня больше всего в sql server profile досаждало- необходимость иметь права, куда большие чем нужные приложению.
Т.е. под стандартной учеткой на чтение данных использование профилировщика- не получится.
Hello World- писать всегда легко, а дальше обычно начинаются подводные грабли.
Rest/Soap вместе на базе одного сервиса- как минимум странно, как максимум плохо. Это два разных принципа построения Api. Один — манипуляции с ресурсов, второй по сути Remote Procedure Call. Если они мешаются, значит что-то явно не так.
Хостинг на Linux- вообще-то Asp.Net WebApi тоже прекрастно хостится там, не совсем из коробки, но можно.
Я ни в коем случаи не против этого framework, и даже его пробовал… просто ваши аргументы- не аргументы.
Оформление в понедельник всех стажеров, которые приходят в эту неделю. Нас было человек 250, стажеры ms, msr и не только разработчики но и nba. Это четко построенный конвеер.
Десятки компов для заполнения анкет, несколько человек с фотокамерам, делать фото на пропуск. Десятки столов с сумками, которые выдают всем стажерам. Везде указатели по следующим этапам. Куча асистентов отвечающих на вопросы.
И так летом почти каждую неделю.
И тут ты понимаешь, что когда в компании 50000+ сотрудников, то по другому ни как. С текучкой хотя бы 10% это надо набирать 5000 человек в год.
Уверен что в Google такая же картина.
А уж из этих десятков тысяч человек уходящих каждый год из microsoft-google-apple в стартапы точно кто-нибудь подастся.
Просто в web.api эта асинхронность очень просто взять и использовать.
www.asp.net/web-api/overview/web-api-clients/calling-a-web-api-from-a-net-client
а конструкция типа
выглядет по страшнее чем
Пару мелочей от зануды.
1- protected RestClient _client = new RestClient(«translate.yandex.net/api/v1.5/tr/»); — обычно считается плохим тоном, тк строка забита жестко.
2- www.nuget.org/packages?q=yandex выложите сюда. Основная проблема на моей памяти со всеми библиотеками, что их найти тяжело. Nuget- это то место от куда все пакеты и качают и начинают их искать.
1-Мое Вам уважение, что Вы это провернули! Задачка не является тривиальной и до нее еще додуматься надо.
2-Почему так важна возможность «хочется, не покидая Management Studio, изменять поведение своих процедур» Вы ведь сами сказали- «иногда требуется».
При этом единственным преимуществом является- отсутствие необходимости перекомпилировать и обновлять clr сборку… При том, что сразу всплывет куча проблема (Ради иногда нужно писать код не на 2 языках, а на 3… а там уже куча всяких тонких моментов всплывет, о которых не рассказывают евангелисты на презентациях)
Если задача одноразовая — то можно и просто на C# через какой-нибудь ef написать маленькую программку, сделать и выкинуть ее.
Если многоразовая-типовая- то вряд ли вам будет нужно менять код. Написать на .net clr без всяких dlr и пусть работает.
Если многоразовая не типовая- то тогда действительно наверное использование более мощного языка программирование оправдано.
питоновскую консоль и в sl вставляли и в веб контролы и еще куда-то… в итоге дальше примеров, не слышно что это кто-то использовал по настоящему.
P.s. в 2012 студии большой кусок management studio встроен уже в ide. Я лично не открываю management studio довольно давно за ненадобностью.