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

Линия бизнес-приложений: Будет ли F # сделать мою жизнь легкой?

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

Это может быть не лучший подход, но это то, что я следую

1. Создайте рабочее приложение сначала (без потоков) и дайте его конечному пользователю играть ради обратной связи.
2. Когда все требования заблокированы, я стараюсь использовать потоки везде, где имеет смысл повысить производительность.

Код для шагов 1 и 2 в подавляющем большинстве отличается, и код потока доминирует над фактическим кодом.

1.Will F # облегчит мне жизнь в случае приложений Business of Business?
2. Существуют ли какие-то особые технологии пользовательского интерфейса, которые лучше всего подходят для F #? Я в основном работаю над ASP.NET и Silverlight. WPF время от времени.
3. Есть ли хорошие примеры линейных бизнес-приложений/демо с F #?

Я не спрашиваю, можно ли разработать приложение Business of Business в F #. Я спрашиваю, сможет ли F # сделать мою жизнь проще разрабатывать приложения Business of Business по сравнению с С#? Моей главной задачей будет потоковая передача и синхронизация пользовательского интерфейса.

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

В моих собственных приложениях LOB F # запускает круги вокруг С# в нескольких областях:

  • Процессы асинхронного управления F # и процессоры почтовых ящиков упрощают работу, чем собственные потоки и даже параллельную библиотеку задач. Поскольку я использую процессоры почтовых ящиков для межсоединения, я даже не помню, как последний раз мне приходилось блокировать или thread.join() что-либо для синхронизации вообще.

  • Определение механизмов бизнес-правил и DSL с объединениями FTW! Каждое нетривиальное приложение LOB, с которым я когда-либо работал, имеет свой собственный язык и интерпретатор правил, и его почти всегда основывается на рекурсивном включении перечисления, чтобы развернуть правила и найти совпадение. В текущем проекте у меня теперь есть 1300+ открытых классов, 900 или около того - это простые классы контейнеров для представления правила. Я думаю, что представление правил в качестве объединения F # существенно уменьшит раздувание кода и сделает лучший движок.

  • Неизменяемый код работает лучше - если вы получаете новый объект с недопустимым состоянием, вам не нужно искать далеко, чтобы найти строку с нарушением кода, все, что вам нужно знать, находится в стеке вызовов, Если у вас есть изменяемый объект с недопустимым состоянием, иногда вам приходится тратить много времени на его отслеживание. Вы можете написать неизменяемый код в С#, но его действительно сложно не отступать от изменчивости, особенно когда вы изменяете объект в цикле.

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

С# обычно хорошо работает, когда:

  • Вы пишете GUI-код или работаете с изменчивыми системами.

  • Предоставление DLL или веб-сервисов многим различным клиентам.

  • Ваш босс не позволит вам использовать нужные инструменты;)

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

Ответ 2

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

С плюсом стороны, связанные с потоками, должны быть относительно безболезненными - рабочие процессы async F # - огромное преимущество. Кроме того, F # Interactive быстро выполняет итерацию и исследование кода. Для меня это огромная польза от С#, так как я могу проверить незначительные изменения кода, не пройдя полную сборку.

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

Ответ 3

@Juliet и @kvb имеют хорошие ответы, я просто хочу повторить, насколько полезен F # для облегчения потоков. В моем сообщении в блоге " Панель инструментов RSS в F #, часть шестой (все это вместе с графическим интерфейсом WPF), я говорю

... Обратите внимание на отличное использование 'async here - я используйте Async.StartImmediate, что означает весь код работает в потоке пользовательского интерфейса (где запускается обработчик Click), но Я все еще могу делать неблокирующие сны которые не забивают пользовательский интерфейс. Это один что F # async просто дует в двери от всего остального.

...

Наша информация "назад" ( "3 минуты" назад ") быстро устареет, если мы не обновляйте его, поэтому мы начинаем цикл который перерисовывается каждую минуту. однажды снова, F # асинхронный удар ногой, поскольку я могу просто напишите это, как если бы это было синхронный цикл в пользовательском интерфейсе нить, но неблокирующий сон вызов гарантирует, что пользовательский интерфейс остается в режиме реального времени. Потрясающие....

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

(Есть ли канонический "пример проблемы" приложения с графическим интерфейсом С#, где вам нужно добавить потоки, чтобы улучшить функционал или поддерживать приложение в течение продолжительной операции? Если это так, я должен проверить его.)

Ответ 5

Чтобы ответить на это, я разместил некоторые мои мысли при использовании F #,

http://fadsworld.wordpress.com/2011/04/13/f-in-the-enterprise-i/ http://fadsworld.wordpress.com/2011/04/17/fin-the-enterprise-ii-2/

Я также планирую сделать видеоурок, чтобы закончить серию и показать, как F # может внести свой вклад в программирование UX.

Я говорю только в контексте F # здесь.

-Fahad