Aplicaciones de la línea de negocio: ¿F # hará mi vida más fácil?

Question

Desarrollo principalmente aplicaciones de línea de negocio. Sin operaciones científicas. Sin cálculos complejos. Solo ata la interfaz de usuario a la base de datos. La única razón por la que utilizo el enhebrado es para hacer un poco de trabajo en segundo plano y aún así mantener la UI respondiendo.

esto puede no ser el mejor enfoque, pero esto es lo que sigo

1.Create una aplicación de trabajo en primer lugar (sin hilos) y darle al usuario final para jugar por el bien de la retroalimentación.
2.Una vez que todos los requisitos están bloqueados, trato de usar subprocesos donde sea que tenga sentido para mejorar el rendimiento.

El código para los pasos 1 & 2 es abrumadoramente diferente y el código de subprocesamiento domina el código real.

1.Will F # me hacen la vida más fácil en el caso de las aplicaciones de la línea de negocios?
2. ¿Hay alguna tecnología de IU particular que se ajuste mejor con F #? Principalmente trabajo en ASP.NET & Silverlight. WPF ahora & luego.
3. ¿Hay algún buen ejemplo de aplicaciones/demostraciones de línea de negocio con F #?

No estoy preguntando si es posible desarrollar la aplicación Línea de negocios en F #. Me pregunto si F # facilitará mi vida al desarrollar aplicaciones de línea de negocios en comparación con C#. Mi principal preocupación será enhebrar la sincronización de la IU &.

Answer 1

Estoy en el mismo barco que tú, haciendo un montón de aplicaciones tipo línea de negocio, nada "divertido" como juegos o compiladores o motores de búsqueda.

Su kilometraje varía, pero al menos en mi propia experiencia, muchos equipos de desarrollo son reacios a entrar directamente en F # porque nadie más en el equipo lo sabe o incluso lo ha escuchado. Y de inmediato, tienes que luchar contra esas preguntas como "¿qué hace diferente de C#?" Si puede convencer a su jefe para que le permita escribir algunas aplicaciones de demostración, ¡adelante!

Con eso dicho, me parece que C# no es muy bueno en las reglas comerciales, pero maneja las GUI como un campeón; La inmutabilidad de F # hace que el desarrollo de la GUI resulte incómodo, pero las reglas de negocio y los flujos de trabajo se sienten naturales. Entonces los dos lenguajes tienen sus propias fortalezas y complementan las debilidades de los demás.

En mis propias aplicaciones de línea de negocio, F # corre en círculos alrededor de C# en unas pocas áreas:

• F # 's flujos de trabajo asincrónicos y procesadores buzón órdenes de magnitud más fácil de trabajar que subprocesos nativos e incluso tareas de la Biblioteca paralelo . Desde que utilicé los procesadores de buzones para la comunicación entre hilos, ni siquiera recuerdo la última vez que tuve que bloquear o enhebrar cualquier cosa para la sincronización.

• Definición de motores de reglas de negocio y DSL con uniones FTW! Cada aplicación LOB no trivial en la que he trabajado tiene su propio lenguaje e intérprete a medias, y casi siempre se basa en activar recursivamente una enumeración para profundizar en las reglas y encontrar una coincidencia. El proyecto actual que ahora tengo contiene 1300+ clases públicas, 900 o más son clases simples de contenedor para representar una regla. Creo que representar las reglas como una unión F # reduciría sustancialmente la inflamación del código y haría un mejor motor.

• código inmutable simplemente funciona mejor - si usted consigue un nuevo objeto con un estado no válido, usted no tiene que buscar mucho para encontrar la línea de código, todo lo que necesita saber es en la llamada apilar. Si tiene un objeto mutable con un estado no válido, a veces debe dedicar mucho tiempo a rastrearlo. Usted puede escribir código inmutable en C#, pero es realmente difícil no caer en mutabilidad, especialmente cuando está modificando un objeto en un bucle.

• I odio nulls. No puedo dar una estimación exacta, pero parece que la mitad de los errores que obtenemos en la producción son excepciones de referencia nula: un objeto se inicializa incorrectamente y usted no lo sabe hasta que tenga 30 cuadros de profundidad en el código. Creo que F # nos ayudaría a escribir más código libre de errores la primera vez.

C# generalmente funciona bien cuando:

• Estás escribiendo código de interfaz gráfica de usuario o trabajar con sistemas inherentemente mutables.

• Exponer un DLL o servicio web a muchos clientes diferentes.

• Su jefe no le permitirá utilizar las herramientas que desee;)

Así que si usted puede conseguir sobre el "¿por qué queremos utilizar un nuevo obstáculo lenguaje", creo F # voluntad de hecho, haz tu vida más fácil.

Answer 2

Esa es una pregunta muy difícil de responder: creo que F # haría que algunos aspectos de tu vida sean mucho más fáciles y algunos más difíciles.

En el lado positivo, tratar con el enhebrado debe ser relativamente sencillo: los flujos de trabajo asincrónicos de F # son una gran ventaja. Además, F # Interactive hace que sea muy fácil iterar y explorar código rápidamente. Para mí, esto es una gran ventaja sobre C#, ya que puedo probar cambios menores en el código sin pasar por una compilación completa.

En el lado negativo, las herramientas para F # no están en C#, lo que significa que no tendrá acceso a constructores de GUI, herramientas de refactorización, etc. Es difícil decir qué tan grande es la productividad golpear esto lo haría sin saber más acerca de su escenario. Una solución alternativa sería crear una solución multilingüe que tenga un front-end C# delgado, pero de nuevo la complejidad puede no valer la pena.

Answer 3

@Juliet y @kvb tienen buenas respuestas, solo quiero reiterar lo útil que es F # para facilitar el enhebrado. En mi blog "An RSS Dashboard in F#, part six (putting it all together with a WPF GUI)", digo

... Tenga en cuenta el uso ingenioso de 'asíncrono' aquí - Me uso Async.StartImmediate, lo que significa todo el código se ejecuta en el hilo de interfaz de usuario (donde el controlador de Click se inicia), pero Todavía puedo hacer bloqueos sin bloqueo que no bloquean la UI. Esta es una forma de que F # async solo expulsa las puertas de todo lo demás.

...

Nuestro “hace” la información (“Hace 3 minutos ”) va a obtener rápidamente rancio si no se actualizan, así que empezamos un bucle que vuelve a dibujar cada minuto. Una vez que de nuevo, F # async patea el trasero, como puedo , simplemente escriba esto como si fuera un bucle síncrono ejecutándose en el subproceso UI , pero la llamada no bloqueo de espera asegura que la IU permanezca activa. Impresionante. ...

pero esa entrada de blog es un ejemplo del uso de F # para codificar manualmente toda la interfaz de usuario. Eso implica deshacerse de todas las excelentes herramientas de GUI que obtienes con C# o VB. Imagino que un enfoque híbrido puede potencialmente generar casi todos los beneficios de ambos (con el costo de tener dos proyectos en la solución donde tu anterior solo tenía uno), pero aún no tengo experiencia directa en compartir aquí.

(¿Hay una canónica "problema de ejemplo" de una aplicación # GUI C, donde es necesario agregar roscado para mejorar perf o mantener la aplicación en vivo durante una operación larga? Si es así, debería comprobar que funciona.)

Answer 4

Algo que le gustaría ver:

The First Substantial Line of Business Application in F#

Una aplicación LOB grande en F #.

Answer 5

Para hacer frente a este he publicado algunos pensamientos de la mina en el uso de 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/

También estoy planeando hacer un video tutorial para terminar la serie y mostrar cómo F # puede contribuir en la programación de UX.

Solo hablo en contexto de F # aquí.

-Fahad