Подтвердить что ты не робот

С# vs F # для программных графических интерфейсов WPF

Я пытаюсь решить, где провести линию по использованию F # и С# в разработке корпоративного программного обеспечения. F # для математического кода не вызывает затруднений. Мне нравится F # для работы с графическим интерфейсом, хотя у него нет поддержки дизайнеров GUI, но, конечно же, в индустрии С# GUI больше ресурсов. Тем не менее, я не слишком хорошо знаком с разработкой С# + XAML GUI, поэтому я заинтересован в том, чтобы ввести предвзятость.

В случае одного клиента у них есть десятки аналогичных графических интерфейсов, которые довольно статичны (меняются ежегодно) и несколько других графических интерфейсов, которые очень динамичны (например, механизмы бизнес-правил). У них уже есть код F # и они уже инвестируют в обучение F #, поэтому наличие навыков не является проблемой. Мое впечатление, что С# + XAML позволяет создавать статические графические интерфейсы (несколько слайдеров, несколько текстовых полей и т.д.), Но я не вижу, как дизайнер GUI поможет с программными графическими интерфейсами, такими как механизм бизнес-правил. Правильно ли я считаю, что для поддержания батареи в основном статических графических интерфейсов (например, для добавления нового поля в 100 отдельных графических интерфейсов) потребуется ручной труд? Кроме того, я прав, думая, что дизайнер GUI мало полезен в контексте сильно программных графических интерфейсов, поэтому что-то вроде механизма бизнес-правил будет написано в основном на С# + XAML с небольшим использованием GUI-дизайнера?

4b9b3361

ОТВЕТЫ

Ответ 1

Я сделал большое количество графического интерфейса и программирования без GUI в С# и F #, в работе и игре, тяжелой программной и статической... и я считаю, что ваше заявленное впечатление является точным и практичным. (заметьте, что я больше знаком с WinForms, чем с WPF, но я не думаю, что разница здесь имеет значение).

Мое впечатление, что С# + XAML позволяет создавать статические графические интерфейсы (несколько слайдеры, несколько текстовых полей и т.д.), но я не вижу, как графический интерфейс дизайнер поможет с программными графическими интерфейсами, такими как бизнес-правила двигатель.

Это мой опыт. Для большинства статических графических интерфейсов я предпочитаю использовать конструктор WinForms с С#. Комбинация инструментов отлично подходит для этих сценариев и более продуктивна, чем ручное кодирование графического интерфейса с F # и без дизайнера (теперь, если бы была поддержка F # с дизайнером, я бы без колебаний предпочел бы это). Я только отдыхаю - это пример, где я предпочел С# с дизайнером WinForms по сравнению с чистым F #.

И для тяжелых программных графических интерфейсов я считаю, что лучше всего избегать конструктора, а не пытаться сделать половину программной половины программной (она становится реальной, беспорядочной, реальной). Поэтому в этих случаях я определенно предпочитаю кодирование GUI в F #, так как все знают, что F # является более выразительным языком;) FsEye является примером, где я предпочел чистый F # над С# с дизайнером WinForms.

Я правильно понимаю, что поддержание батареи в основном статической GUI (например, добавление нового поля в 100 отдельных графических интерфейсов) потребует ручной труд?

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

Кроме того, я прав, думая, что дизайнер GUI мало полезен в контекст сильно программных графических интерфейсов, что-то вроде бизнеса правил будет записываться в основном на С# + XAML с небольшим использованием дизайнер GUI?

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

Ответ 2

Недавно я создал приложение для визуализации ориентированного графа, используя только F # и WPF.

Для "программных" частей графического интерфейса я по существу создал пользовательские элементы управления WPF, которые я мог бы выполнять с привязкой данных и MVVM.

Для статических частей я использовал XAML с готовыми и настраиваемыми элементами управления WPF.

Я использовал FSharpX WPF Type Provider для привязки MVVM.

И эта "книга" помогла мне немного начать. http://wpffsharp.codeplex.com/

Некоторые вещи не приходят естественным образом с F # и WPF, но почти во всех случаях было найдено достаточно элегантное решение. Некоторые строки привязки данных WPF стали большими и громоздкими.

Ответ 3

Я не знаю, как точно ответить на вопрос, так как его трудно удержать, поэтому я просто даю вам свои 0,05 $:

Если вы используете WPF с хорошим MVVM (есть даже Rx-Versions, на которые влияет FP-land), вы не будете писать код (или почти нет) - и с провайдерами типа WPF и всеми другими отличные вещи, которые вокруг вас уже могут писать приложения WPF-F # без каких-либо проблем (даже поддержка дизайнеров не проблема), просто используйте BLEND, если сможете, - если вы еще не можете разделить GUI на немой С# -lib.)

так почему бы мне не написать большинство графических интерфейсов в 100% F # тогда?

Ну, если честно... это отсутствие рефакторинга и инструментов, таких как ReSharper - это просто разочаровывает, что я не могу найти F # -символы или типы, потому что в VS/R # er нет никакой лишней поддержки.

Странно, но написание MVVM-кода, в котором вам нужно создать многообразный код для ваших Viewmodels, кажется, проще сделать на С# с правильными инструментами прямо сейчас (например: я могу настроить R # er, чтобы вставить мне весь код для публичных probertys с частными/публичными сеттерами и INotifyPropertyChanged на основе внутренних полей, просто нажав - и выбрав правильный вариант - это создаст много очень тупых кодов, но это намного быстрее, чем вы могли бы сделать в F #)

Ответ 4

Как вы уже указали, F # - гораздо более скудный навык среди программистов в общей ИТ-индустрии, тогда как каждый мужчина и его собака знают С# (или, в этом отношении, Java, C/С++, которые легко переводить).

Таким образом, с чисто управленческой точки зрения, скорее всего, имеет смысл идти с С# + XAML над F # из-за ряда факторов:

  • Заработная плата программиста - найм гуру F # добавляет довольно много к бюджету зарплаты.
  • Время разработки - это может быть аргументировано в любом случае см. 1 для хорошего сравнения.
  • Корпоративный риск - использование F # значительно увеличивает коэффициент риска в каждой из категорий:
    • Программист оставляет компанию и берет с собой интеллектуальную собственность.
    • Программист оставляет компанию, и компания не может нанять замену = > срок просрочки проекта
    • Компания не имеет достаточных показателей для оценки времени, необходимого для проекта.
    • Язык становится разрозненным, и код должен быть портирован (не так уж большой проблемой, но все же более высокий риск, чем С#).
    • Etc. и др.

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

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

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

Ответ 5

Я вижу много запутанных ответов и решений здесь. F # и С# могут быть объединены в решении. Пусть С# управляет пакетами управления GUI и F #. Кроме того, XAML против WinForms не имеет проблем. С XAML, Есть более чем достаточно места для кода, чтобы сделать все и все, что вам нужно. Если вы используете WinForms, я верю, что вам нужно немедленно уйти от него. Например, WPF является гораздо более гибким и чрезвычайно мощным с параметрами GUI, намного превосходящими возможности WinForms. Не говоря уже о связующей способности XAML. XAML является статическим, но хорошо взаимодействует с кодом и может связываться с любым и всеми .NET-языками. Используйте F #, используйте С# вместе и определенно оставите мир WinForms навсегда. Вот небольшой проект, который я сделал. Он использует только комбинатор WPF, Silverlight, WCF, F #, С# и VB.NET. WinForms не был затронут, и если вы посмотрите внимательно, вы увидите, что с этим WinForms потребуется возраст. Я мог бы закончить это только одним языком, но обмен помог сэкономить время в зависимости от ситуации, но я только пошел вперед, а не назад. WinForms, а также все другие устаревшие опции игнорировались и никогда не использовались.