2009-06-03 29 views
11

Estamos en el medio de la creación de una aplicación Silverlight LOB de n niveles y estamos considerando el uso del servicio .NET RIA. No tenemos claro dónde encaja esto en relación con nuestra API actual del servicio WCF. Nuestra arquitectura actual es:.NET RIA Services/WCF Services

Silverlight < ->WCF Servicio < ->lógica de negocios < ->Entity Framework Modelo < -> Base de datos

Después de haber visto Presentación de Nikhils Mix 09 parecería que .NET RIA Services reemplazaría nuestras secciones WCF y BusLog:

Silverlight < ->Servicios RIA < ->EF Modelo < ->DB

que está muy bien, esperamos que tenemos que tener un punto final SOAP API estándar expuesta para su uso por otras aplicaciones (Biztalk, Integración, etc.). ¿Se pueden exponer .NET RIA Services como extremos SOAP sin el requisito asincrónico?

¿Qué tan fácil es implementar un servicio WCF sobre un servicio .NET RIA? ¿Conoces algún buen ejemplo en línea de esto?

Gracias, Marcos

Respuesta

10

Sí - En la siguiente CTP de Servicios RIA vamos a tener un muy buen apoyo para la definición de servicio WCF (a través de Astoria y WCF vainilla eventual) que expone la lógica de negocio de Servicios RIA. Entonces tendría dos cabezas en su implementación de Servicios RIA.

Silverlight < ---> RIA Servicios < ---> Modelo EF < ---> DB WCF Servicios < --->

yo diría que este modelo tiene sentido si el objetivo principal es la aplicación de Silverlight, sin embargo, si el objetivo principal es el servicio WCF, me quedaría con el modelo que tienes hoy ... ¿Eso ayuda?

..brad

+0

Gracias, brad, tu consejo va de la mano con lo que estamos haciendo. Es una lástima que no podamos exponer un punto final WCF de .NET RIA Services ya que necesitamos tener un API de servicio, pero manejar entidades manualmente sobre WCF nos está causando una gran cantidad de dolor en la actualidad. Mark –

0

Estamos pensando en el mismo escenario exacto. En este momento, estamos pensando en ir con este modelo:

Silverlight < -> Servicios RIA < -> WCF Servicio < -> lógica de negocios < -> Entity Framework Modelo < -> Base de datos

Podremos alojar nuestros servicios WCF en una variedad de enlaces. Utilizaremos una llamada inProc de RIA a WCF para la aplicación Silverlight. Para los consumidores externos de los servicios de WCF, los alojaremos con un punto final wsHttp.

Por lo tanto, en nuestro caso obtenemos lo mejor de ambos. Los servicios de RIA se convierten en parte de un conjunto de servicios de presentación para nuestra aplicación que facilita la carga de programación de la aplicación Silverlight (es decir, asincrónica). La desventaja es que hemos agregado una capa adicional.

¿Pensamientos?

+0

Seré honesto, no creo que esta sea una buena idea. Al poner los Servicios RIA sobre su Servicio WCF, perderá todos los beneficios de su modelo EF una vez que pase la capa WCF, por lo que construirá sus Servicios .NET RIA encima de los objetos desconectados y los objetos proxy que son creados por servicios específicos, por lo que no son compatibles con otros servicios donde se usan. –

+0

Bien Mark, entonces parece que también nos dirigimos hacia un mal camino. Nuestro camino era: Silverlight <-> Servicios RIA o servicio WCF WCF <-> Fachada <-> Aplicación de Servicios de dominio <-> Modelo <-> NHibernate <-> SQL Los servicios de RIA || WCF Service vive fuera de nuestro firewall y está diseñado solo para esta aplicación. La capa Fachada está adentro, sigue siendo una fachada por aplicación. Los servicios de aplicaciones y el modelo de dominio son POCO y compartidos por todas nuestras aplicaciones. Nuestra elección es presentar los servicios de RIA para obtener una configuración simplificada y Autenticación y autorización mágica, o simplemente WCF? – basscinner

+0

Parece que esto es todo un cambio para la próxima versión :-) Los Servicios de RIA se llaman Servicios WCF RIA y admitirán puntos finales adicionales. –

Cuestiones relacionadas