Estoy exponiendo algunos métodos CRUD a través del servicio WCF, para algunos objetos de datos persistieron en una base de datos a través de NHibernate. ¿Es un buen enfoque utilizar las clases NHibernate como contratos de datos, o es mejor envolverlos o reemplazarlos con algunos otros contratos de datos? ¿Cuál es su enfoque?NHibernate clases como contratos de datos
Nuestro equipo acaba de pasar por unos cuantos meses debatiendo este punto de diseño, así que tengo un montón de enlaces para compartir ;-)
Respuesta corta: que "debe" traducir de sus clases de NHibernate en un modelo de dominio.
Respuesta larga: Creo que la respuesta a esto es una cuestión de principios. Si alguna vez desea ser interoperable, debe no usar Conjuntos de datos como sus DTO (I love Hanselman's post on this). No digo que nunca sea una buena idea; claramente la gente ha tenido éxito al hacerlo. Solo sé que estás cortando esquinas y es una propuesta arriesgada.
Si tiene un control total sobre las clases en las que está insertando los datos, puede construir un modelo de dominio agradable y simplemente asignar los datos de NHibernate a esas clases. Es muy probable que tenga problemas graves al hacerlo, ya que IList <> (al que se asigna una bolsa < >) no se puede serializar. Tendría que escribir su propio serializador, o usar algo como NetDataContractSerializer, pero pierde la interoperabilidad.
Necesitará medir la cantidad de trabajo involucrado en la creación de algunas clases contenedoras, y la traducción entre, pero luego tiene completa flexibilidad en cómo se verá su modelo de dominio. Entonces, puede hacer cosas (como lo hemos hecho) como la generación de código para sus mapas y objetos NHibernate. Entonces, sus contratos de datos sirven como una abstracción de sus datos, como deberían.
P.S. Es posible que desee echar un vistazo a ADO.NET Data Services, que es una forma RESTful de exponer sus datos, que, en este punto, parece ser la opción más interoperable para exponer sus datos.
No tengo experiencia directa en hacer esto, pero he enviado Datasets a través de WCF antes y eso funciona muy bien. Creo que su mayor problema al usar NHibernete como objetos de datos sobre WCF será la falta de interoperabilidad (como es también el caso cuando se usan conjuntos de datos). El cliente no solo debe usar .NET, sino que también debe usar NHibernate. Esto va en contra de los principios de SOA, pero si conoce con seguridad que no va a reutilizar este componente, entonces no hay una buena razón para no hacerlo.
Al menos vale la pena intentarlo.
Los objetos NHibernate son generalmente solo objetos POCO, por lo que podrían serializarse en XML con bastante facilidad. Ese XML es portátil y puede ser leído por cualquier aplicación. No estoy seguro de estar de acuerdo en que los conjuntos de datos sean un método "interoperable" de envío de datos a través de un servicio WCF. –
Lo siento Jeffrey, no quise dar a entender que los conjuntos de datos fueran interoperables. Ellos no son Intenté decir que usted debería poder usar NHibernate en WCF, pero eso no sería interoperable al igual que el uso de DataSets funciona, pero no es interoperable. Editaré para aclarar –
No querrá exponer directamente su modelo de dominio, pero asigne el dominio a algún tipo de mensaje cuando llegue al límite del proceso. Podría aprovechar NHibernate para hacer el trabajo de mapeo por usted. En este caso, tendrías 2 asignaciones, una para tu modelo de dominio y otra para tus mensajes ligeros.
SI necesita hacer un mapeo, hay una excelente herramienta llamada Automapper disponible. para asistir. –
Lo que más me preocupa acerca del uso de clases de contenedor, es la capacidad de mantenimiento de ese código. ¿Cuál fue su decisión final sobre esto (es decir, la decisión de su equipo)? ¿Siempre vas con envoltura, o es solo una cuestión de decisión en una situación específica? –
Completamente comprensible; ese fue el mayor debate. Básicamente, realmente no hay nada que hacer al respecto; es un código personalizado Sin embargo, dado que nuestras clases/mapas NHibernate están gen'd (¡rocas de CodeSmith!) Directamente de la base de datos, y nuestro modelo de dominio se realiza a través de diagramas de fábrica de servicio de MS, la traducción es la * única * cosa que debe escribirse a mano. Dada la flexibilidad, mantener ese pequeño código personalizado vale la pena. –