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é?
Respuestas:
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.
fuente
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.
fuente
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.
fuente
Esta parte es bastante preocupante:
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.
fuente
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.
fuente
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.
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)
No es un problema.
¿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.
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.
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.
No estoy seguro de lo que eso significa.
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.
fuente
¿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
fuente
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.
fuente