Pregunta de arquitectura para el desarrollo de Tier .Net

Question

Hola a todos soy bastante nuevo en el proceso de desarrollo por niveles. Actualmente estoy desarrollando una aplicación y tengo algunas preguntas básicas sobre las mejores prácticas/preguntas de arquitectura con la tecnología actual. Voy a usar WCF como capa de servicio. Tenga en cuenta que estoy tratando de desacoplar las cosas tanto como sea posible. No quiero que nada en los niveles superiores tenga que saber nada en los niveles inferiores, que es una de las razones por las que no me gusta LINQ TO SQL o el marco de entidades.

1) ¿Cuál es la mejor manera de pasar datos entre los niveles? Sé que un conjunto de datos o una tabla de datos sería fácil, pero no creo que aprobar esta estructura de datos inflada entre los niveles sea la mejor solución. También la depuración sería más difícil si los datatables/datasets fueran grandes. ¿Tal vez una gran variedad de objetos POCO sería la mejor solución o hay una mejor manera?

2) La siguiente pregunta es un poco más complicada. Muchas aplicaciones tendrán diferentes vistas de los datos. Es posible que tenga varios informes, una variedad de cuadrículas de datos y tal vez un cuadro o dos. ¿Cómo se hace para diseñar su nivel de datos para esto? ¿Acabas de diseñar una función de tipo "Obtener" para cada tabla y luego tratas de combinarlas en vistas útiles para decir una cuadrícula o un informe en tu capa de negocios o tienes una función especializada para cada vista que necesites en la capa de negocios.

Para ser sincero, no me gusta ninguna de las soluciones. Si decide utilizar la lógica especializada por visión, deberá crear un objeto POCO (suponiendo que va a devolver una matriz de objetos POCO) por vista. Si decide más adelante, necesita agregar más columnas a una de las vistas, entonces estaría rompiendo el código existente (porque está cambiando la interfaz en el POCO). Si decide devolver una vista de cada tabla e intentar combinarla en la capa de negocios, eso podría volverse realmente complicado. TSQL se ha unido por una razón :). Además, es posible que esté devolviendo muchos más datos de los que necesita dependiendo de su diseño, que sería ineficiente.

Tengo más preguntas pero las guardaré para más adelante. No quiero que este post se convierta a grande :)

NCAGE

Answer 1

Creo que se está perdiendo un poco con la idea de no querer el nivel de datos a saber nada de la capa de negocio o de la interfaz de usuario. En una herramienta ORM (LINQ to SQL, por ejemplo), las propiedades de sus entidades están determinadas por los datos. Realmente no hay razón para no hacer esto. Tener entidades fuertemente tipadas no es lo mismo que tener lógica de negocios/UI en el nivel de datos, y generalmente es algo bueno; cómo llegas ahí depende de ti.

SIEMPRE defiendo usar un componente fuertemente tipificado para pasar datos en lugar de un repositorio de propósito general como un DataSet/Table/Row/View/etc.

¿Quizás podría ampliar un poco sobre lo que le ha alejado de este enfoque?

Answer 2

Estas son muy buenas preguntas. Hay muchas respuestas posibles y muchas arquitecturas posibles. Te recomiendo que leas un manual sobre el tema. Patterns & Practices has a very good one. Es gratis, completo y analiza en profundidad las preguntas que hace. Ninguna guía de arquitectura es perfecta, pero como punto de partida, no creo que pueda equivocarse al estudiar los conceptos básicos.

Answer 3

Buenas preguntas. Cosas importantes, esto. En general, una de las mejores formas de acercarse a las soluciones escalonadas es observar las interfaces. Las interfaces son una forma de proporcionar "puntos clave", que pueden servir para varios propósitos útiles.

Dentro de las soluciones por niveles, las interfaces sirven para imponer los comportamientos de los niveles; efectivamente al definir el conjunto de comportamientos que espera, desacopla la implementación de los niveles.Es decir, siempre que mi nivel implemente la interfaz correctamente, la implementación es algo de lo que no necesito preocuparme en absoluto.

Traigo esto (y ES RELEVANTE) porque al definir tus Interfaces, también necesitarás definir tus datos que pasan entre los niveles. Entonces, al definir lo que debe suceder entre los niveles, terminas definiendo qué datos pasan; y al mismo tiempo, definir un conjunto estricto de datos que se pasa.

Un punto relevante aquí acerca de la segregación es que no se debe pasar información entre los niveles sobre la implementación de un nivel. Es decir, al definir su Interfaz y ser estricto con respecto a la implementación, debe poder hacer que la implementación del nivel se pueda volver a implementar desde cero, conocer únicamente la interfaz y reemplazar la otra implementación sin problemas.

Sabiendo esto hace las cosas simples; el uso de objetos antiguos simples generalmente mantendrá sus interfaces limpias y adecuadas; y evita que sus estructuras de datos se hinchen. También sirve para evitar la tentación de utilizar cierta información sobre la implementación de un nivel en otro nivel.

Por supuesto, para hacer esto correctamente, es útil tener una visión a largo plazo del problema a resolver; ¿Cuál es el conjunto de operaciones que el usuario querrá hacer? Esas operaciones generalmente se resuelven en "verbos" que se ajustan bien a las definiciones de interfaz que definen el contrato que implementarán los objetos de negocio. Los conjuntos de datos en los que funcionarán sus objetos comerciales definirán el conjunto de vistas que necesita tener en su base de datos. De esta manera, puedes mantener limpiamente tu separación.