Каков наилучший подход к модульности и независимости от платформы? - PullRequest
2 голосов
/ 29 августа 2008

Надеюсь, этот вопрос не так широк, как может показаться на первый взгляд. Я занимаюсь разработкой программного приложения в свое <sarcasm> объемное </sarcasm> свободное время. Я бы хотел, чтобы он был кроссплатформенным и модульным. На данный момент, поскольку я все еще на этапе планирования, я могу выбрать практически любой язык и набор инструментов.

Это усложняет, а не облегчает, потому что, по-видимому, существует множество способов достижения обеих целей (модульность, агностицизм платформы).

Моя основная предпосылка заключается в том, что безопасность, хранение данных, взаимодействие с операционной системой и конфигурация должны обрабатываться приложением-контейнером, но большая часть других функций будет предоставляться через подключаемые модули. Если бы мне пришлось описать это на высоком уровне (без полного отказа от моей идеи), это было бы одно приложение, которое может выполнять много разных работ, все посвященные одной и той же цели (есть много разнородных вещей, но все данные должны взаимодействовать и быть высокодоступными).

Это не новая идея и не особо экзотическая. Тем не менее, я сталкиваюсь не столько с тем, как это сделать (я могу придумать много способов), но с тем, какой метод лучше.

Например, я знаю, что Eclipse практически воплощает то, что я описываю, но я нахожу Java-приложения в целом (и Eclipse не исключение) слишком большими и медленными для того, что мне нужно. Ditto настольные приложения написаны на Python и Ruby (это отличные языки!)

Я не против перекомпилировать кодовую базу для разных платформ как нативные. Тем не менее, C и C ++ имеют свои собственные проблемы.

Как разработчик C #, я предпочитаю управляемый код. Но пока что я не продан на Mono (я могу быть уверен).

У кого-нибудь есть какие-нибудь идеи / опыт / конкретные любимые фреймворки, которыми можно поделиться?

Ответы [ 6 ]

1 голос
/ 29 августа 2008

Если вы планируете заниматься разработкой на Python, вы всегда можете использовать pyrex для оптимизации некоторых более медленных частей.

1 голос
/ 29 августа 2008

Если вам нужна независимость от платформы, вам придется выбирать между производительностью и усилиями по разработке. C ++ может быть быстрее, чем Java (это спорный FWIW), но с Java вы получите гораздо большую независимость от платформы. Python и Ruby находятся в одной лодке.

Я сомневаюсь, что .NET будет намного быстрее, чем Java (в конце концов, они оба языки VM), но большая проблема с .NET - независимость от платформы. Mono имеет благородную цель и пока что удивительно хорошие результаты, но она будет всегда играть в догонялки с Microsoft на Windows. Вы можете принять его ограничения, но это не то же самое, что иметь идентичные многоплатформенные среды, которые есть в Java, Python и Ruby. Также: инструменты разработки и поддержки .NET сильно перекошены для Windows и, вероятно, всегда будут.

IMO, вам лучше всего ориентироваться на Java ... или, по крайней мере, на JVM. Если вам не нравится язык Java (и я полагаю, что это не так, как C # dev), у вас есть варианты Jython, JRuby и Scala. С JVM вы получаете очень хорошую независимость от платформы, хорошую производительность и доступ к огромному количеству библиотек и средств поддержки. Почти всегда есть библиотека, порт или реализация Java, которые будут делать то, что вам нужно. Я не думаю, что у любой другой платформы есть такое же количество вариантов; в этой гибкости есть реальная ценность.

Что касается модульности: это больше о том, как вы строите программное обеспечение, чем о том, какую платформу вы используете. Я не знаю много о архитектурах плагинов, которые вы описываете, но я предполагаю, что это будет возможно практически на любой современной платформе, которую вы выберете.

1 голос
/ 29 августа 2008

Просто для примера: для приложений .NET есть CAB (блок составного приложения) и руководство по составному приложению для WPF. В основном оба варианта представляют собой набор из нескольких шаблонов проектирования, ориентированных на модульность и слабую связь между компонентами, аналогичными архитектуре подключаемого модуля: у вас есть инфраструктура IOC, базовые классы MVC, слабосвязанный брокер событий, динамическая загрузка модулей и другие вещи. .

Итак, я полагаю, что именно такую ​​инфраструктуру шаблонов вы пытаетесь найти, но не специально для .NET. Но если вы видите CAB как набор реализаций шаблонов, вы можете увидеть, что почти на каждом языке и платформе есть какая-то форма уже встроенных или сторонних сред для отдельных шаблонов.

Так что мой результат будет:

  1. Изучите (если вы не знакомы) некоторые из этих шаблонов проектирования. В качестве примера можно привести структуру CAB для документации WPF: Шаблоны в библиотеке составных приложений
  2. Создайте свою архитектуру, думая о том, какой из этих шаблонов, по вашему мнению, будет полезен для того, чего вы хотите достичь, сначала , не думая о конкретных реализациях шаблонов или продуктах .
  3. Как только вы определите свои «архитектурные требования» более конкретно, поищите отдельные каркасы, которые помогут реализовать каждый из этих шаблонов / функций для языка, который вы решите использовать, и соберите свою собственную прикладную платформу на их основе.

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

1 голос
/ 29 августа 2008

Планируете ли вы настольный компьютер или веб-приложение?

Все здесь, кажется, думают, что Mono великолепен, но я все еще не думаю, что он готов для промышленного использования, я бы приравнял mono к тому, где вино, отличная идея; когда это работает, это работает хорошо, а когда это не ... хорошо, вам не повезло. mod_mono для Apache чрезвычайно затруднителен и его трудно правильно запустить.

Если вы стремитесь к рабочему столу, ничто не сравнится с платформой eclipse RCP (Rich Client Platform): http://wiki.eclipse.org/index.php/Rich_Client_Platform.

Вы можете собрать все окна, linux, mac под одним и тем же кодом, и все компоненты пользовательского интерфейса являются родными для ОС. И RCP выигрывает в модульности вниз, у него есть плагин архитектуры, которая не имеет себе равных (из того, что я видел)

Я работаю с RCP уже 1,5 года, и я не знаю, что еще могло бы заменить его, это # ​​1 в его нише.

Если вы полностью против java, я бы посмотрел wxWidgets с python или C ++

0 голосов
/ 10 октября 2008

Для настольных приложений, написание на интерпретируемом языке и использование кросс-платформенного инструментария пользовательского интерфейса, такого как wxWidgets, поможет вам продвинуться к независимости от платформы (вам просто нужно быть осторожным, чтобы не использовать другие модули, кроссплатформенный, используйте такие вещи, как модуль os.path Python, вместо таких вещей, как config_path = "/home/$USER")

Тем не менее, чтобы создать хорошее кроссплатформенное приложение, вам придется делать некоторые вещи по-разному на каждой платформе ..

Например, OS X, вероятно, наиболее отличается - предпочтения обычно хранятся в ~ / Library / Prefernces / как .plists, пользовательские интерфейсы, как правило, основаны на плавающих окнах, с единственной панелью меню, прикрепленной вверху экран.

Полагаю, именно здесь вступает в действие модульность. В приведенном выше примере предпочтений у вас может быть класс UserConfig, для которого у вас есть версии для ОС. Windows one хранит данные конфигурации в соответствующей папке Application Data или в реестре. Mac OS использует файлы .plist в ~/Library/Preferences/, а unix'y использует ~ / .dotfiles.

0 голосов
/ 29 августа 2008

С моим ограниченным опытом моно я могу сказать, что я довольно продан на этом. Обнадеживает тот факт, что есть активное развитие и много постоянных усилий, чтобы привести его в соответствие с новейшими технологиями .Net. Невероятно полезно иметь возможность использовать существующие навыки .Net на разных платформах. У меня были похожие проблемы с производительностью, когда я пытался выполнить некоторые базовые задачи в Python + PyGTK - возможно, их можно заставить работать в правильных руках, но приятно не беспокоиться о производительности 90% времени.

...