Estamos a punto de embarcarnos en unesfuerzo de integración para eliminar un montón de bases de datos de Access y SQL Server y obtener todo en un sistema empresarial coherente. También hay una serie de otros sistemas (contabilidad, CRM, nómina, MS Exchange) que contienen datos críticos que necesitamos integrar (usar para la validación de datos en otros sistemas), informar y exponer. Es probable que algunos de estos sistemas cambien en los próximos años, por lo que necesitamos aislar nuestros sistemas para estar listos para el cambio.
Idealmente, podríamos exponer nuestras formas en unde manera consistente en tantos de nuestros sistemas como sea posible sin tener que volver a desarrollarlos para cada sistema. Actualmente estamos apuntando a SharePoint (2007 y pronto 2010), Office (2007 y pronto 2010 - Word, Excel, PowerPoint y Outlook), Reporting Services, aplicaciones de consola .Net, aplicaciones de Windows .Net, extensiones de shell y con la posibilidad de exponer alguna funcionalidad en dispositivos móviles (BlackBerries actualmente, quizás iPhones más adelante) y a través de nuestro sitio web.
Estamos trasladando el desarrollo a Visual Studio 2010(desde 2005) antes de migrar a SharePoint 2010 y Office 2010. Dado que la mayor parte de nuestro desarrollo está actualmente dirigido al marco .Net (principalmente en C #), parece lógico seguir con esto a menos que haya alguna razón convincente para cambiar los marcos / plataforma para algunos aspectos.
Estamos pensando en su base de datos estándar-> DatosCapa de integración-> Capa de objetos empresariales-> Capa de servicios web (o REST )-> Aplicación de cliente más hacer nuestra propia aplicación de cliente con formularios WPF (¿o algo más?) Que también pueden exponerse en los sistemas MS (SharePoint, Office, Windows )
Entonces, no queremos mucho, solo todo:) Básicamente, necesitamos aislarnos de los cambios en la base de datos y los sistemas, crear una API que pueda usarse en todos nuestros sistemas y luego hacer que esta funcionalidad esté disponible en nuestras aplicaciones cliente.
Estoy muy interesado en recibir consejos de cualquiera que tengaconsejos sobre cómo lograr esto. ¿Deberíamos ver la Biblioteca Empresarial como un lugar para comenzar o rodar la nuestra? ¿Es REST con ASP.Net MVC2 una solución mejor que los servicios web para un sistema como este? ¿WPF entregará la reutilización de formularios o hay algo mejor?
Respuestas
1 para la respuesta № 1Recomiendo una sola aplicación compuesta parasu aplicación de línea de negocio. Entonces no hay necesidad de "reutilizar formularios", las vistas están todas allí e integradas juntas. Todo su acceso a datos puede pasar por una única capa reutilizable y todas las aplicaciones de terceros se comunican con su sistema a través de técnicas de SOA.
El grupo de Patrones y Prácticas de Microsoft proporcionaAlgunos marcos para desarrollar una única aplicación modular, extensible y enchufable que se puede implementar a través de un solo mecanismo de implementación. Si tiene control total sobre la plataforma de sus usuarios finales (Windows), le recomiendo usar WPF Prisma y si no lo haces, te recomiendo usar SilverlightPrisma. Si aún no se ha cambiado a la tecnología WPF / Silverlight, puede desarrollar una buena aplicación compuesta de formularios Windows Forms con los componentes Unity de Prism o SCSF, que está mucho más desarrollado para WinForms. (Nota: WPF puede alojar controles WinForms y WinForms puede alojar controles WPF, por lo que puede crear una solución híbrida con componentes existentes a medida que avanza hacia un sistema empresarial completo y coherente). Tenga en cuenta que SCSF / CAB y Prism aprovechan algunos conocidos patrones de diseño, por lo que deberá familiarizar a su equipo con los fundamentos de OO y los patrones de diseño.
En cuanto a la solución móvil, creo que puede desarrollar vistas WPF para Windows Mobile, lo que le permite reutilizar la aplicación con diferentes vistas en dispositivos móviles.
WCF es sin duda el mejor marco SOA para hacer comunicación entre aplicaciones en .NET.
Si tiene flujo de trabajo, cadenas de aprobación o necesidades de enrutamiento de documentos, use WF. Incluso puede integrar editores de flujo de trabajo en la aplicación compuesta para que los usuarios finales puedan modificar y actualizar los flujos de trabajo a medida que cambian las necesidades comerciales, todo sin llamarlo.
Si aún no está utilizando un ORM, entonces le recomendaría nHibernar. No desarrolle su propia capa de acceso a datos para la integración con RDBMS, es una tontería; ver aquí.
Mirar en usar ClickOnce para el despliegue de esta aplicación; tiene soporte incorporado para permitir que su aplicación detecte e instale actualizaciones automáticamente.