ASP.Net o WPF (C #)? [cerrado]

31

Nuestro equipo está dividido en esto y quería obtener opiniones de terceros.

Estamos creando una aplicación y no podemos decidir si queremos usar la aplicación de escritorio .Net WPF con un servidor WCF o la aplicación web ASP.Net con jQuery. Pensé en hacer la pregunta aquí, con algunas especificaciones, y ver cuáles serían las ventajas y desventajas de usar cualquier lado. Tengo mi propio favorito y siento que soy parcial.

Idealmente, queremos construir la versión inicial del software tan rápido como podamos, luego reducir la velocidad y tomar tiempo para incorporar las características / componentes adicionales que deseamos más adelante. Sobre todo, queremos que el software sea rápido. Los usuarios revisan registros durante todo el día y los retrasos en la carga de registros o la actualización de pantallas mata su productividad.

Detalles de la aplicación:

  • Estoy estimando alrededor de 100 pantallas diferentes para la versión inicial, con planes para agregar muchas pantallas adicionales más adelante después del lanzamiento inicial.
  • Estamos buscando utilizar la comunicación bidireccional para recordatorios y sistemas de eventos.
  • Actualmente tiene que admitir alrededor de 100 usuarios, aunque se nos ha pedido que permita un crecimiento de hasta 500 usuarios.
  • Tenemos múltiples ubicaciones

Elementos a tener en cuenta (tal vez no inicialmente en algunos casos, pero en futuras versiones):

  • Espacio para agregar componentes adicionales después del lanzamiento inicial (hay muchos de estos ... tal vez funcionen aquí que la aplicación inicial)
  • Teclado de navegación
  • El rendimiento es imprescindible
  • Velocidad de producción a la versión inicial
  • Bajo mantenimiento general
  • Soporte futuro
  • Integración de Softphone / escáner

Nuestros desarrolladores:

  • Tenemos 1 programador que ha estado aprendiendo WPF en los últimos meses y fue el que sugirió que usemos WPF para esto.
  • Tenemos un segundo programador que está familiarizado con ASP.Net y que puede ayudar con el proyecto en el futuro, aunque no trabajará mucho hasta el lanzamiento inicial, ya que dedica su tiempo a mantener nuestro software actual.
  • Estoy yo, que he trabajado con ambos y estoy cómodo en cualquiera
  • Tenemos una empresa externa que se encarga de la gestión del proyecto, y son una empresa ASP.Net.
  • Planeamos contratar 1-2 personas más, sin embargo, primero debemos saber en qué dirección vamos

Medio ambiente:

  • Los usuarios generales están en el servidor de Windows 2003 con Terminal Services. Se conectan utilizando clientes delgados WYSE a través de una conexión RDP. El personal administrativo tiene sus propias PC con XP o superior. Los usuarios pueden especificar su propia resolución, aunque están limitados a usar IE como navegador web.
  • Otras ubicaciones se conectan a nuestra red a través de una conexión MPLS

Basado en eso, ¿qué elegirías y por qué?

Rachel
fuente
Me encantan todos los votos, pero realmente me gustaría escuchar algunas opiniones más sobre esto :)
Rachel
3
¿Qué haces que requiere 100 pantallas inicialmente ?
Steven A. Lowe
Esa estimación incluye muchas pantallas parciales. Por ejemplo, la pantalla principal se divide en un montón de "piezas" que se pueden agregar / eliminar / mover / cambiar de tamaño según las necesidades del usuario. Cada uno tiene su propio conjunto de datos, su propia vista de edición y su propio conjunto de acciones que se pueden realizar. Estoy contando estos como separados en lugar de una sola pantalla ya que cada uno es muy diferente.
Rachel
Use .NET MVC 3, JQuery y HTML5
Oliver Picton
1
Hola @kmote, terminamos con WPF y quedamos bastante contentos con la decisión. Permitió mucha más flexibilidad en la construcción de la interfaz de usuario, y descubrí que fue bastante rápido de construir en comparación con una solución basada en la web. Lamentablemente, el proyecto se canceló después de un año debido a otras prioridades, sin embargo, si me presentaran la misma opción nuevamente, tomaría la misma decisión.
Rachel

Respuestas:

17

Ciertamente me parece una aplicación WPF, con mucha interacción del usuario y potencialmente interactuando con el hardware. Puede entregar la aplicación a través de Hacer clic una vez para que la implementación no sea un problema. Su aplicación WPF puede acceder a un servicio WCF y entregar los datos como binarios para que el rendimiento sea excelente. Comenzaría a leer sobre WPF y a familiarizarme con él lo antes posible.

Walter
fuente
+1 Además, con TODAS esas pantallas, probablemente querrás construir la mayor cantidad de reutilización posible en tu aplicación (código y GUI)
Jon Onstott
+1 Supongo que se requiere "integración de Softphone / escáner", supongo que la única forma es WPF. O tal vez sea posible usar Silverlight
Jiew Meng
15

Respuesta marginal: ambos. Obtenga la capa de servicio correcta, es fácil tener un cliente grueso que haga todo (WPF) y un cliente web rápido para hacer las cosas más comunes (ASP.NET). Deja la puerta abierta al cliente móvil, etc., más adelante.

Wyatt Barnett
fuente
Eso es lo que estamos pensando hacer ... Aplicación de cliente WPF para la mayoría de los usos con una versión web ligera para informes o acceso limitado.
Rachel
2
Haga +1 en esto, escriba las agallas de no presentación en el lenguaje .NET que le resulte cómodo, luego use la mejor herramienta para cada tarea de presentación (es decir: la aplicación web usa la interfaz ASP.NET para esta aplicación, el escritorio usa WPF / Winforms / etc)
heretik
Inicialmente, los usuarios pueden encontrar que ASP.NET es "lo suficientemente bueno", especialmente si significa obtener más piezas de la aplicación antes.
JeffO
8

Si solo tiene un programador que ha estado aprendiendo WPF y está considerando que su equipo dé el salto a WPF, ¿por qué no usar Silverlight en su lugar? Obtiene muchas de las ventajas de WPF pero aún mantiene la capacidad de dejar su proyecto como una aplicación web. Dado que está buscando tener un gran proyecto modularizado, tendría sentido usar PRISM con WPF o Silverlight para simplificar MVVM.

Mi equipo recientemente tomó la decisión de usar Silverlight sobre asp.net. Ha sido una elección fantástica para nosotros. Inicialmente, solo teníamos un desarrollador que conocía Silverlight. Luego tomamos una clase de entrenamiento de una semana que fue en su mayoría inútil, pero al menos nos mojamos los pies. Al final, tuvimos que contratar a dos contratistas para ayudarnos con la creación de la mayor parte de nuestro marco de UI. La mayoría de nuestro equipo aún no confía en sus habilidades de Silverlight. Yo mismo, el miembro inicial del equipo con conocimiento de Silverlight, y los dos contratistas son los que hacen la mayor parte del desarrollo de SL. Después de eso tenemos dos miembros de back-end dedicados. Diría que nos tomó aproximadamente 2 meses después de tomar la decisión de mudarnos a Silverlight que realmente teníamos algo concreto preparado. Sin embargo, ahora tenemos un producto maravilloso que se parece mucho a una aplicación del lado del cliente que se ejecuta dentro de un navegador web y no se instala en ninguna máquina localmente. El desarrollo ha sido inferior a un año en total y estamos casi listos para lanzar o primer candidato de lanzamiento.

Algunas cosas a considerar:

  • WPF o Silverlight, cualquiera que elija, habrá una cantidad justa que sus desarrolladores deberán aprender.

  • Silverlight puede quedarse sin navegador si es necesario. Si hace esto, es bastante fácil configurarlo de modo que si alguna vez lanza una nueva versión, el programa SL instalado fuera del navegador se actualizará automáticamente.

  • Silverlight no incluye todos los controles que tiene WPF.

Mi nota final es que si desea producir código lo más rápido posible, entonces es bastante obvio que debería usar ASP.NET. Mis principales dudas con ASP es que, a menos que disciplines a tu equipo, es fácil que un proyecto ASP.NET se vuelva desordenado y desordenado. Si cree que podrá lidiar con la sobrecarga inicial de ponerse al día con las tecnologías, Silverlight o WPF le permitirán muchas posibilidades maravillosas.

Kavet Kerek
fuente
Estamos en una situación muy similar y me pareció interesante escuchar tu historia, gracias. Consideraré Silverlight, aunque hasta ahora solo he usado WPF. Si vamos con WPF, planeamos hacer nuestra sección de Informes en Silverlight, así que planeé aprenderlo eventualmente
Rachel
Estoy en medio de la conversión (reescritura de lectura) de una aplicación ASP.NET en Silverlight, básicamente porque ASP.NET no se adapta a lo que queremos que haga.
ChrisF
1
Solo para su información: recuerde que Silverlight no será un producto importante de la EM, y en algunos casos, la gente dice que puede estar descontento. Estoy de acuerdo en que sería bueno considerarlo, solo agregue esta información a su lista de posibles inconvenientes.
Paige Watson
1
Consideraría encarecidamente WPF sobre Silverlight para este tipo de aplicación. WPF se puede implementar fácilmente como una XBAP (aplicación de navegador xaml), generalmente con solo un par de cambios en el código del archivo de configuración. WPF tiene todo lo que Silverlight hace y más, además de que WPF obtiene mucho más soporte. El único inconveniente es que si bien Silverlight se puede implementar potencialmente en más sistemas operativos (incluso Linux con el proyecto Moonlight), WPF requiere .Net en el cliente, por lo que es estrictamente Windows.
Morgan Herlocker
2
No sé si Silverlight se descontinuará, pero algo relacionado es el artículo de Mashable Microsoft Shifts From Silverlight to HTML5 . Personalmente, consideraré seriamente las aplicaciones web puras si es posible a través de complementos de escritorio o basados ​​en propiedad donde sea posible
Jiew Meng
7

Esta parte es bastante preocupante:

Los usuarios generales están en el servidor de Windows 2003 con Terminal Services. Se conectan utilizando clientes delgados WYSE a través de una conexión RDP. El personal administrativo tiene sus propias PC con XP o superior. Los usuarios pueden especificar su propia resolución, aunque están limitados a usar IE como navegador web.

WPF no es excelente para conexiones de escritorio remoto / cliente ligero. Las animaciones no serán uniformes y cualquier imagen compleja (incluso degradados) ralentizará la respuesta de la IU hasta un rastreo. El personal administrativo con máquinas típicas de XP retro también tendrá problemas de rendimiento con aplicaciones WPF complejas (debido a pequeñas cantidades de RAM y GPU defectuosas).

Si sigue la ruta WPF para obtener gráficos ricos, prepárese para los trucos de rendimiento de último minuto cuando descubra que las máquinas objetivo tienen diez años. Apéguese a las pantallas estáticas y use .NET 4.0 ya que el rendimiento de WPF ha mejorado dramáticamente desde 3.5.

Ed Andersen
fuente
Gracias ... esa es realmente una gran preocupación para mí, aunque hasta ahora parece que podemos reducir los gráficos si el usuario está en una conexión RDP y las pruebas han funcionado bien.
Rachel
2

Técnicamente, creo que la combinación WPF / WCF es la mejor solución.

Sin embargo, no estoy convencido de que su programador WPF existente realmente tenga la experiencia para este proyecto. WPF es un gran cambio en la programación de los procesos de pensamiento de la programación de Winform, por lo que deberá pensar detenidamente si realmente tiene las habilidades suficientes en el equipo para llevar a cabo esta ruta.

Michael Shaw
fuente
1
+1 'Aprender durante un par de meses' podría significar cualquier cosa: prepárate para una curva de aprendizaje empinada.
Kirk Broadhurst
1

Interesante. Eso suena sorprendentemente familiar para una aplicación que acabamos de comenzar en mi empresa (integración de teléfono sip y escáner y todo).

Elegimos Silverlight con un enfoque en SOA para que luego se pudiera crear una aplicación WPF si fuera necesario.

Espacio para agregar componentes adicionales después del lanzamiento inicial (hay muchos de estos ... tal vez funcionen aquí que la aplicación inicial)

Estamos utilizando MEF en la capa de servicio y construyendo puntos de extensión (interfaces de complementos que describen ciertos puntos donde planificamos la extensibilidad o integración con otros sistemas)

Teclado de navegación

No es un problema.

El rendimiento es imprescindible

¿Qué tipo de desempeño? ¿Rendimiento percibido (snappy-ness) o rendimiento numérico? Esto último podría ser un problema con una aplicación web / silverlight. Para el primero, nuestra aplicación pasa por muchos registros, como el tuyo, pero podemos predecirlos y buscar previamente registros mientras los usuarios están trabajando en los actuales. Los tiempos de 'carga' son cero para esa sección de nuestra aplicación.

Velocidad de producción a la versión inicial

Depende del conjunto de habilidades. Pero de manera realista, todos siempre quieren llegar al mercado lo más rápido posible, por lo que no es un argumento.

Bajo mantenimiento general

Al igual que la velocidad de producción, tampoco es un argumento y se reducirá a prácticas de diseño y codificación. Si está hablando en términos de mantenimiento de hardware, puede optar por una aplicación en la nube.

Soporte futuro

No estoy seguro de lo que eso significa.

Integración de Softphone / escáner

Silverlight 4 ahora permite el acceso a la cámara web / micrófono (esperamos hacer videoconferencias entre aplicaciones, así como la integración de sorbos), por lo que si está utilizando un servidor telefónico, puede escribir uno usted mismo. No conozco ninguno existente, pero esto podría ayudar.

De lo contrario, es posible que tengas que hacer un pirateo feo (ya no tengo una referencia al artículo / s, lo siento) o no tienes más remedio que tener una aplicación WPF que pueda interactuar con el sistema de archivos. SL4 puede salir del navegador, pero solo puede acceder a ciertas partes del sistema de archivos. Es probable que ninguno de ellos sean las partes que necesita para interactuar con un teléfono sorbo.

¿Te refieres a escáner de documentos? No estoy seguro de eso. Estamos usando escáneres manuales / de código de barras, y funcionan como cualquier otro dispositivo de entrada y no son un problema.

Steven Evers
fuente
1

¿necesita una aplicación altamente receptiva para que la gente la use todo el día? usar WPF; le resultará más fácil reutilizar componentes GUI en WPF sobre ASP / MVC también (en mi humilde opinión

Sí, jquery y otros son geniales, Silverlight es genial, pero las aplicaciones de escritorio son aún más eficientes

para el back-end, WCF está bien

Steven A. Lowe
fuente
0

Tendré que recomendarle que use WCF para su capa de servicio debido a la escalabilidad y la seguridad. Para la capa de presentación puede usar Silverlight o ASP.NET, Silverlight es como Flash, pero es difícil de entender y tiene una curva de aprendizaje alta al principio, principalmente cuando se trabaja con datos. ASP.NET es más fácil de usar, pero necesitará muchos ajustes y javascript para usarlo de manera eficiente.

Victor Gil
fuente
1
El plan es tener una capa de servicio WCF independientemente de lo que elijamos hacer para la capa de IU. Estamos tratando de decidir si queremos WPF / Desktop o ASP / Web para la aplicación cliente. Incluso si optamos por una aplicación de escritorio, existe una alta probabilidad de que tengamos un portal web para acceder a un subconjunto de elementos, como informes.
Rachel