¿La mejor práctica para el servicio WCF grande?

Question

¿Cuál es la mejor práctica para escribir un servicio wcf bastante grande, que contiene una gran cantidad de OperationContracts y DataContracts?

¿Cómo separaría áreas funcionales en varios contratos? ¿Sería mejor crear un punto final para cada área funcional?

¿Hay alguna manera de mantener separada la fuente de las diferentes partes, pero aún así utilizar solo un servicio para todas ellas?

¿Dónde obtengo buena información sobre cómo planificar los contratos, qué incluir, cómo dividir ...?

Answer 1

Esa ha sido una gran pregunta sobre los servicios desde su creación. SOA hecho con éxito es SOA planificado en la medida en que usted está hablando. Habiendo dicho eso, siempre me he inclinado más hacia dividir los servicios, pero usarlos de manera compuesta. Es decir, varios puntos finales cuando tiene varios contratos, pero la mayoría de ellos solo son consumidos por unos pocos puntos finales que son consumidos por personas que no pertenecen al servicio. (wow, eso fue un bocado, ¿incluso tenía sentido?)

Además, aconsejaría tener el menor número posible de contratos. Demasiados contratos pueden conducir a una mala administración. Un buen diseño de contrato ayudará a limitar el número de puntos finales y llamadas de servicio. La eliminación de los conceptos de OO del diseño del contrato es una forma de hacerlo. El diseño del contrato es un tema masivo en sí mismo, pero basta decir que a través de una buena planificación del contrato (por adelantado), viene un buen diseño del servicio.

Maarten Mullender writes a great blog en diseño WCF, y es una lectura obligada. También están surgiendo algunos grandes libros SOA/WCF.

Algunos buenos libros:

• Pro WCF: Practical Microsoft SOA Implementation
• Programming WCF

Answer 2

Esto ha sido útil para mí se trata de la página web idesign.net y fue escrito por Juval Lowy:

WCF Coding Standard

Answer 3

Saldré de la pista y diré que he usado contratos WCF monolíticos, contratos separados funcionalmente (con un máximo de diez métodos según las pautas de Juval en su libro), y también he probado una arquitectura de manejo de mensajes donde un servicio tiene un único método que toma un mensaje base y manejadores que 'saben' cómo desenvolver y procesar el mensaje después de que cruza el cable.

Soy un gran admirador de este último si tienes .NET en ambos lados de la valla. Oren tiene un screencast sobre la idea con código. No sé cuáles son tus necesidades pero esto está funcionando para mí.

http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx

Dicho esto, si ya está viniendo de "Necesito un gran servicio WCF", entonces ir a un método probablemente no se va a cortar para usted. Si eso es cierto, los servicios WCF de programación de Juval Lowy son el estándar que debe mantener en su diseño.

Answer 4

que tienen un puesto aquí sobre cómo las operaciones individuales deben diferir de las operaciones tradicionales de código:

http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

Usted debe terminar solamente con las operaciones para eventos de negocios reales. Si alguna vez se detiene y piensa "Necesito habilitar el soporte de transacciones en mi servicio web", eso significa que no ha diseñado la operación con un alcance lo suficientemente amplio. Nunca debe tener que habilitar el soporte de transacciones del servicio web.

Recomiendo encarecidamente el blog de Bill Poole para conceptos SOA de nivel superior. Aquí hay un post para empezar:

http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html

Answer 5

Sé que esto es una entrada antigua, pero estoy pensando en los servicios de la misma manera como pienso de los objetos en la programación.

Manténgalas al mínimo para lo que deben hacer. Por supuesto, no ir al extremo, pero estoy tomando decisiones basadas en entidades de datos.

Un servicio para una cuenta, uno de los productos, etc.

No está seguro de lo que cualquiera pensaría que aunque ...