2009-10-16 2 views
19

Я разрабатываю свое первое приложение ASP.NET MVC, и я верю, что Script # может мне очень помочь. Но он не может найти ресурс, необходимый для поддержки моего развития.Должен ли я использовать ScriptSharp

Не удалось найти сайт Codeplex; Существует только одно руководство, которое очень хорошо, но этого недостаточно; Я мог найти очень мало учебников; Я знаю, что Script # использовался для разработки сценариев ASP.NET MVC и что источник MVC распространяет библиотеку.

Но похоже, что он используется только внутри Microsoft.

Где я могу найти другие ресурсы ???

Вы действительно считаете, что сценарий # будет продолжен, а новые версии будут развернуты и должны использоваться сторонними projetcs ???

Заранее спасибо

+0

См. Также http://stackoverflow.com/questions/788933/what-advantages-can-scriptsharp-bring-to-my-tool-kit –

ответ

19

Не бойтесь Javascript, это beautiful и powerful язык. И с такими фреймворками, как jQuery, Prototype и Dojo, DOM-манипуляция и AJAX значительно упрощены, а проблемы с перекрестным браузером - это в основном история.

О Script #, Я согласен с this answer by mcintyre321. Последний релиз более года назад + закрытый исходный код = нет для меня.

ОБНОВЛЕНИЕ январь/2010: с момента написания этого ответа были выпущены новые версии сценариев #. Он по-прежнему закрыт, но автор упоминает открытый источник его после 1.0

ОБНОВЛЕНИЕ Май 2011: Script# is now open source.

+3

Хорошо, но как насчет скрипта #? –

+1

IMHO Javascript - это путь. См. Также http://stackoverflow.com/questions/788933/what-advantages-can-scriptsharp-bring-to-my-tool-kit –

+3

Обратите внимание, что недавно был выпущен новый выпуск. проект не мертв :-) –

0

Я использую jQuery. Это действительно хорошо. Но я верю, что мне более комфортно работать с C#. Даже если это подмножество.

3

Как и другие, я бы порекомендовал JavaScript (а именно jQuery). Если вы захотите продолжить Script #, блог Никхила Котари может стать для вас хорошим ресурсом. http://www.nikhilk.net/ScriptSharpIntro.aspx - Говоря, я думаю, вы обнаружите, что вы более продуктивны с помощью jQuery. Существует большая база данных публичных плагинов сообщества, поэтому вам не обязательно будет изобретать велосипед на все, что вы хотите сделать. jQuery plugins instead of ASP.NET Controls

4

Я использую Script #, я думаю, что это здорово. Вы можете использовать его с любым фреймворком, jQuery, dojo, но вам придется обернуть фреймворк, это может быть большой работой ...

Это только полезно, поскольку я вижу, что он позволяет вам разрабатывать javascript в строго типизированной среде. Я думаю, что это ОГРОМНОЕ преимущество. Я отказываюсь развиваться на слабо типизированных языках, поскольку обслуживание - это кошмар.

Если вам нравится работать на слабо типизированном языке, тогда вам не понадобится Script #.

6

IMHO Script # подходит для крупных проектов только с действительно «богатым» веб-клиентом. Участвуя в таком проекте, я мог только сказать, что сценарий # нам очень помог. Замечание josephhemingway о строго типизированном на 100% верно для такого случая. Также это позволило нам быстро внедрить новых разработчиков .NET без какого-либо JS-фона. Предполагая, что планы Nikhil Kothari с открытым исходным кодом летом 2008 года, мы даже декомпилировали (никому не говорим, это незаконно), и он представил дженерики, перегрузки операторов, различные исправления ошибок и т. Д.

НО. Тогда поддержка скрипта # исчезла. Проект по CodePlex с обсуждениями и отслеживанием проблем был закрыт (интересно, что части структуры были опубликованы там незадолго до этого). Нет обновлений, нет планов на будущее, нет объяснений. После такой вещи я бы рассмотрел Script # только после того, как он стал открытым исходным кодом, чтобы дать сообществу возможность его поддерживать. Например. на CodePlex.

+2

Теперь он открыт на github. –

+0

Из любопытства вы все еще используете Script # и считаете, что пожертвовали эти изменения сообществу, теперь это на github? –

+0

Нет, лично я не, так как поддержка JS в Visual Studio и вообще созрели значительно, а текущий проект имеет чуть менее сложный клиент. В настоящее время скриптовые скриптовые инструменты C# для JS не являются открытыми (они публикуются двоично в ScriptSharp.dll), поэтому я не могу поместить эти вещи в github, но я обязательно попытаюсь, когда (или если) их появляется исходный код. – Val

1

Сегодня вышел релиз, поэтому приятно видеть, что он по-прежнему активен.

Независимо от предыдущего отсутствия обновлений и того, что он не был открыт, я все равно буду использовать его поверх простых js. Вы можете прекратить использование сценария # в любое время и более вперед с помощью «скомпилированных» js, если вам это не нравится.

Я согласен с вами, что Val, хотя он действительно подходит только для крупных проектов на основе js. Я не думаю, что вы получите большую выгоду от использования его для выполнения основных функций страницы, таких как подтверждение ввода формы и т. Д. Вероятно, не стоит его настраивать.

Если, однако, вы сильно используете javascript и вам нужно реплицировать OOP, то я думаю, что это обязательно. Такие вещи, как рефакторинг, становятся такими легкими, с простой js я бы никогда не рефакторировал, потому что это было слишком сложно реализовать, со временем мой код стал беспорядком.

Wow Val у вас есть дженерики, чтобы работать в нем, я впечатлен, было ли это трудно? Поддержка носителей будет отличной, так что это будет метод и перегрузка оператора. Вы уверены, что его декомпилировать незаконно, мне нужно будет посмотреть, не являются ли это условиями использования.

2

Wow Val, у вас есть дженерики для работы в , я впечатлен, было ли это трудно? Поддержка носителей будет отличной, поэтому будет перегружать метод и оператор. josephhemingway

Все дело в том, что анализатор ScriptSharp поддерживает полный синтаксис C# 2.0. Единственное, что нужно, это создать надлежащую JS. Не так много работы, учитывая динамическую природу JS. Дженерики будут действовать как Java-стиль, т. Е. Нет поколений для каждого набора аргументов закрытого типа, всего один класс.

Вы уверены, что это незаконно декомпилировать, мне придется иметь взгляд, чтобы увидеть, если это условие использования. josephhemingway

Да, это незаконно. EULA, показанное в настройке, ясно упоминает об этом.

11

Вкратце, мой ответ: если вам нравятся мощные среды IDE, которые работают на Windows, OOD и C#, используйте ScriptSharp. Он более удобен и структурирован и достаточно стабилен для использования в серьезных проектах. Он также может быть легко расширен, как показано ниже, и другими проектами.

Поскольку это еще один поток, индексированный Google, в котором люди ссылаются на сценарий # и jQuery как на взаимоисключающий, я просто хотел указать, что некоторые люди объединяют эти два мира, и в этом случае я могу развязать много сил, сделав это. Я предлагаю совершенно бесплатно и многоразовый библиотеки для доступа к JQuery 1.4 из сценария # проектов, а также полный исходный код для решения порождающего его (почти исключительно из собственного файла API документации Jquery): стандарт

http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp

4

Short ответьте НЕТ. Подождите, пока не появится TypeScript.

Сценарий # действительно крут, но MS решила не поддерживать его вообще. Причина в том, что они работают над лучшей версией этого - TypeScript (http://www.typescriptlang.org/) Он добавляет поддержку всего, что вам нужно, на статическом языке (intellisense, проверка типов, интерфейсы, классы и т. д.), но по-прежнему очень похож на JS, и что еще более важно - подтверждает новый стандарт ECMA Script 6. (в отличие от сценария # или Google Dart)

0

Также я хотел бы добавить, что вы обязательно должны использовать ScripSharp, когда планируете разрабатывать мультиплатформенные проекты. Например, в настоящее время я пишу свой код библиотеки обработки изображений для платформ .NET, JavaScript (ScriptSharp), Android (Mono) на C#. Также я планирую в будущем переносить свой код на iOS (Mono) и Windows Phone. И я думаю, что это отличное повторное использование кода и минимизация времени разработки!

1

Другое преимущество использования ScriptSharp, о котором никто не упомянул, заключается в том, что если вам нужно взаимодействовать с C# (используя AJAX/REST/SOAP), вы можете использовать те же определения классов в обоих местах, и убедитесь, что у вас есть интерфейс правильно определено, потому что это тот же исходный файл! Я попытался использовать логику в общих исходных файлах с минимальным успехом из-за того, что Corelib от ScriptSharp не на 100% совместим с C# corelib. Но он отлично подходит для определения файлов данных.

Смежные вопросы