Entity Framework Brainmush Kerfuffle Spectacular

Question

He estado navegando por todas las cosas nuevas de EF y WCF en .NET 4 para un gran proyecto en sus primeras etapas, y creo que mi cerebro ahora se ha convertido oficialmente en lodo. Es el primer trabajo de desarrollo a gran escala que he hecho en .NET desde los 1.1 días. Como de costumbre, todo debe hacerse ayer, así que estoy tratando de ponerme al día.

Esto es lo que necesito unir, cualquier chequeo de cordura o guía sería muy apreciado. Se puede pensar que el proyecto en sí mismo es esencialmente un sistema elegante de comercio electrónico, con múltiples clientes, tanto en la web como en Windows, que se conectan a los servidores centrales con datos en vivo.

En el lado del servidor:

• un servicio WCF, la implementación usando EF para conectarse a un almacén de datos de SQL Server (que probablemente terminará tener muchos cientos de mesas y todos los demás pertrechos de un sistema de DB complejo)
• clases subyacente utilizado para EF y WCF deben ser extensible tanto a propiedad y clase (es decir, campo y nivel de registro), para la validación, la seguridad , auditoría de alto nivel y otra lógica personalizada

En el lado del cliente:

• cliente WCF
• Subyacente clases el mismo que el del lado del servidor , pero con algunos de los personalizaciones que no están presentes
• Cuando una el objeto se actualiza en el cliente , preferiblemente solo las propiedades modificadas deben enviarse al servidor
• El WCF del lado del cliente detalles API probablemente terminará siendo publicados públicamente, por lo sensibles del lado del servidor consejos de implementación no deben ser filtró a través de la API a menos absolutamente inevitable - esto incluye atributos de EF en propiedades y clases

requisitos generales:

• la eficiencia de la red es importante, la medida en que no lo hacen querer hacer que se * en * eficiente desde el primer día - Me puede tráfico datos de prever y servidor creciente carga de trabajo de manera exponencial dentro de unos pocos años
• La base de datos se desarrolló por primera vez, por lo que los (POCO, C#) clases generadas por EF se basará en él.De alguna manera que hacerse adecuado para tanto EF y WCF en cliente y servidor , y tienen varias capas de personalización, pero parece como si-escrito encargo para cada escenario

Lo sentimos, este es tan abierto, pero como dije, mi cerebro se ha convertido completamente en lodo y me he confundido hasta el punto en que estoy congelado.

¿Alguien podría apuntarme en la dirección general de cómo construir las clases para hacer todo esto? Honestamente, muchas gracias.

Answer 1

Unos pocos indicios en ningún orden en particular:

• POCO sería el camino a seguir para evitar dependencias en las clases de EF en sus objetos de datos.
• Considere agregar una capa intermedia basada en objetos de transferencia de datos para hacer frente a sus "propiedades únicas modificadas" que se pasan (este requisito será la parte difícil). Estos DTO se pasarán entre el servicio y los clientes para intercambiar modificaciones
• Utilice un modelo de comunicación sin estado (sin sesión WCF) para poder implementar el equilibrio de carga y la conmutación por error muy fácilmente.
• Comparta el POCO entre el cliente y los servicios, use la creación de subclases en el servidor para agregar la información personalizada interna.

Se podría terminar en el lado del servidor con al menos:

• Un proyecto para los contratos de servicio y la DTO (compartido)
• Un proyecto para la POCO (compartido)
• Un proyecto para la capa de servicio WCF
• Un proyecto para la lógica de negocio (llamar por la capa de WCF)

Answer 2

tengo algunas notas a sus necesidades:

un servicio WCF, la implementación usando EF para conectarse a un almacén de datos de SQL Server (que probablemente va a terminar tener muchos cientos de mesas y todo la otra pertrechos de un complejo sistema de DB)

¿se va a construir única capa de acceso a los datos expuestos como conjunto de servicios WCF o lógica de negocio pesada expuesta como servicios WCF? Esto afecta fuertemente el resto de sus requisitos. Si quiere hacer el primer caso, consulte los Servicios de datos de WCF. En el último caso revisa mis otras notas.

clases que se han empleado para EF y WCF deben ser extensible tanto a una propiedad y la clase (es decir, el campo y el registro) de nivel, para la validación, la seguridad, alto nivel auditoría y otra lógica personalizada

Divida sus clases de datos en dos conjuntos. Internamente, sus servicios utilizarán clases de POCO implementadas como objetos de dominio. Los objetos de dominio se materializarán/persistirán por EF (necesita .NET 4.0) y también contendrán lógica personalizada. Si usted quiere construir pesada capa de negocio que también debe pensar en el diseño de dominio impulsada = repositorios, raíces agregados, etc.

Subyacente clases el mismo que el del lado del servidor , pero con algunas de las personalizaciones no está presente

El segundo conjunto de clases de datos será Objetos de transferencia de datos que serán expuestos por los servicios de WCF y compartidos entre el servidor y los clientes. Los objetos de su dominio se convertirán en DTO al enviar datos al cliente y los DTO se convertirán en objetos de dominio cuando regresen del cliente.

Sus servicios de WCF deben construirse en la parte superior de la lógica comercial - objetos de dominio/servicios de dominio. Los servicios de WCF deberían exponer las interfaces gruesas (en lugar de las interfaces de conversación CRUD) donde DTO transfiere datos de varias operaciones de dominio. Esto también lo ayudará a mejorar el rendimiento al reducir el número de viajes de ida y vuelta entre el cliente y el servicio.

Cuando un objeto se actualiza en el cliente , preferiblemente sólo los modificados propiedades deben ser enviados al servidor

Creo que esto sólo puede lograrse mediante la correcta definición de las OTD o quizás por alguna serialización personalizada.

la eficiencia de la red es importante, en la medida en que no queremos para que sea * en * eficiente desde el primer día - Puedo prever el tráfico de datos y el servidor creciente carga de trabajo de manera exponencial dentro de unos pocos años

Como ya se mencionó, debe diseñar su servicio para estar listo para el balanceo de carga y también debe pensar en el almacenamiento en caché (distribuido) - consulte AppFabric. La buena idea es usar servicios sin estado.

La base de datos se desarrolló por primera vez, por lo que la (POCO, C#) clases generadas por EF se basa en ella.

Parece un requisito simple, pero puede modelar fácilmente una base de datos que será difícil de usar con Entity Framework.

el principal consejo:

Su proyecto se ve grande y compleja por lo que la primera cosa que debe hacer es contratar a algunos desarrolladores con experiencia con WCF, EF, etc. Cada una de estas tecnologías tiene algunas trampas por lo que es realmente un gran riesgo usarlos en tal escala sin tener gente experimentada.