Java с EMF и RCP против C#

Мы думаем о переключении технологии для наших будущих проектов с C++ на Java или C#. Поэтому, естественно, сейчас идет большая дискуссия о том, что выбрать. Проблема в том, что ни у кого из нас нет промышленного опыта работы с EMF или RCP, который было бы неплохо иметь, если бы он соответствовал нашим потребностям.

поэтому я хотел спросить вас, что вы предпочитаете. наша программа:

  • gui тяжелый (много диалогов, свойств)

  • довольно большие модели (сериализованный xml сейчас занимает около 15 МБ)

  • приложение должно быть интегрировано в наш framework-application-center

  • формат данных (xml и двоичный) должен быть таким же, как наш текущий формат

  • необходимо графическое редактирование (создание, перемещение, соединение фигур + редактирование их свойств)

  • много похожих, но крошечных разных объектов в модели данных

и собственно вопросы:

  • есть ли эквивалент EMF в С#?

  • есть ли эквивалент RCP в C#? (например, команды для редактирования модели данных, графического интерфейса, ...)

  • Является ли редактирование графического интерфейса в RCP таким же хорошим и гибким, как в формах Windows или WPF?

  • насколько жестким/гибким является EMF?

  • у нас есть много взаимозависимостей между моделями данных (некоторые контролируют другие или допускают разные параметры для них) - как бы вы их моделировали?

  • какой из вариантов вы бы выбрали?

большое спасибо за любой совет или мнение

Манни


person manni    schedule 31.08.2010    source источник


Ответы (3)


Как разработчик Java я не могу много сказать о C#, но могу дать вам обзор стороны Java: есть несколько хороших вариантов для RCP (наиболее известный, конечно, Eclipse, но есть и другие, такие как NetBeans). Кривая обучения довольно крутая, но как только вы запустите «hello world», все станет намного проще. Программирование с графическим интерфейсом не является проблемой (у вас есть несколько вариантов, и существует множество бесплатных и коммерческих виджетов), и у вас есть несколько способов работы с XML. Вообще почти для всего есть (часто бесплатная) библиотека. Так что, если вам нравится иметь выбор, Java для вас.

С другой стороны, язык C# технически впереди. Java7 может уменьшить разрыв, но не сократит его, это точно.

Если вы хотите иметь как преимущества JVM (открытость, широкое распространение, независимость от платформы, множество библиотек...), так и преимущества современного языка, вам следует взглянуть на Scala (вы можете смешивать код Scala и Java без проблем). Scala очень инновационный, сочетающий в себе объектно-ориентированные и функциональные возможности, но все еще очень «доступный» для программистов, привыкших к синтаксису в стиле C++/Java.

person Landei    schedule 31.08.2010
comment
и большое спасибо за сторону Java тоже. при переходе на java мы, безусловно, будем придерживаться самой java и не будем использовать scala. Я просмотрел несколько попыток и руководств по склеиванию gmf-rcp-emf вместе, где связь между gmf и rcp кажется самой сложной. Кто-нибудь работает со всеми тремя техниками вместе? (или использовать rcp вместе с emf?) - person manni; 01.09.2010
comment
Самая большая трудность, с которой мы сталкиваемся при использовании java, заключается в том, чтобы интегрировать приложение в нашу структуру приложения, которая по-прежнему будет на C++. В настоящее время у нас есть приложение центра приложений, в котором окна подприложений закреплены, будет сложно добиться такой тесной интеграции между программой Java и приложением фреймворка С++. Поскольку это обязательное требование, мы должны найти способ сделать это. дополнительно мы используем библиотеку ключа, для которой нам нужно использовать файл jni. Кроме того, написание служб Windows (которые тоже понадобятся) может быть затруднено в java. - person manni; 01.09.2010

Я совсем не знаком с EMF и RCP, но из того, что я понял с первого взгляда, в .Net определенно есть «эквиваленты». Однако я сильно предвзят, так что не верьте мне на слово.

Существуют инструменты для создания классов данных из xml/xsd и наоборот (xsd.exe), средства графического интегрированного моделирования внутри Visual Studio и т. д.

И есть WPF, который я настоятельно рекомендую для любого проекта (не только графически-тяжелого); с объектной моделью легко работать, она имеет декларативный дизайн графического интерфейса (XAML) и значительно упрощает создание инструментов, подобных диаграммам (таких, как вы описали), по сравнению со старыми технологиями .Net, такими как WinForms. Особенно обратите внимание на MVVM (Model-View-ViewModel) для наиболее распространенного шаблона при работе с WPF/Silverlight.

person Alex Paven    schedule 31.08.2010
comment
спасибо за ответ, несколько дней назад я также более подробно рассмотрел wpf, и он кажется довольно удобным (за исключением размытого рендеринга текста, к которому вы должны привыкнуть). Большая трудность заключается в том, чтобы убедить старых программистов оконных форм перейти на wpf :) Можете ли вы порекомендовать какие-либо инструменты моделирования для визуальной студии, с которыми у вас есть опыт? - person manni; 01.09.2010
comment
На самом деле проблема с размытым текстом значительно улучшилась в .Net 4, и есть несколько вариантов ее тонкой настройки. Что касается инструментов моделирования... В большинстве случаев я прекрасно справляюсь с тем, что встроено в Visual Studio (дизайнер классов, дизайнер Entity Framework и т. д.); в редакциях Visual Studio Ultimate/Architect их еще больше, но я прекрасно обхожусь без них (они довольно дорогие). В Tangible (tangible-engineering.com) тоже есть инструменты для моделирования, но они меня не особо впечатлили. . Visual Paradigm (visual-paradigm.com) выглядит лучше, но не использовал их широко. - person Alex Paven; 01.09.2010

Для основной части приложения я настоятельно рекомендую Eclipse RCP + EMF (Eclipse RAP также является плюсом, поскольку вы можете получить приложение из одного источника и получить многофункциональное веб-приложение Ajax «бесплатно»).

Если вам нужен доступ к нативным функциям, вы всегда можете написать его на другом языке или использовать JNI, или реализовать форму IPC, или использовать веб-сервисы (SOAP), или REST-JSON, или DBus, или любой другой любимый механизм связи, который вам нравится.

Иногда я вызываю инструменты Linux из своего Java-приложения для выполнения этой работы (например, «ssh someserver» или «rsync») и чувствую себя комфортно при этом. Я не считаю веским поводом приобретать «чистую библиотеку SSH для Java» или «чистую библиотеку Rsync для Java», когда другие инструменты отлично справляются со своей задачей, и я могу приступить к следующей интересной задаче.

Кстати, хотя я склоняюсь к Eclipse и JVM (примечание: язык Java не мой любимый, я предпочитаю Scala и Groovy, но с EMF проще работать на языке Java), у меня есть некоторый опыт работы с .NET. Хотя в .NET есть и хорошие стороны (во-первых, C# превосходит язык Java, но это все, во-вторых, Microsoft предлагает больше встроенной функциональности, чем Sun/Oracle дает Java[SE] API), есть и некоторые вещи, которые вам нужно учитывать.

Во-первых, это кроссплатформенность. Хотя есть Mono, в целом .NET трудно портировать. Хотя вам это может не понадобиться, это может пригодиться. Кроме того, Eclipse RCP не только «более кроссплатформенный», но и превосходит готовые функциональные возможности, предоставляемые .NET Framework. (Я знаю, что это несправедливое сравнение, более справедливо сравнивать его с Visual Studio Shell)

Во-вторых, лицензия, затем инструменты и стоимость (всего три пункта). Весь инструментарий Eclipse находится в свободном доступе. Они с открытым исходным кодом (вы можете исправить любую ошибку, внести патч). Лицензия открыта, и вы можете по праву создавать коммерческие продукты поверх нее.

В-третьих, это функциональность. Внутри самого RCP так много функций, что в сочетании с EMF, другими проектами Eclipse и остальной экосистемой Java (не говоря уже о языках JVM) у вас есть много вариантов базовой функциональности.

См. также: http://eclipsedriven.blogspot.com

person Hendy Irawan    schedule 22.12.2010