capa de negocio con múltiples objetos con todas las propiedades de llenado de DB o un objeto con sólo un subconjunto llena

Question

Estoy construyendo una media del tamaño del sistema y estoy frente a un problema que probablemente algunos de ustedes han enfrentado antes.En mi capa de negocio puedo devolver objetos de negocio con un subconjunto de propiedades que son importantes para que el negocio de método, yo estoy preocupada porque puedo terminar con mucho los objetos con nombres sin sentido o sólo uno, donde sólo un subconjunto de las propiedades se llenan en un método dado.Permítanme poner un ejemplo.

Caso 1

Por ejemplo, un usuario que pertenece a una ciudad, que a su vez pertenece a un estado y un país, User, City, State y Country son tablas en mi base de datos con una gran cantidad de campos, pero quiero una lista de los usuarios con una lista de Pedidos, así que crear un objeto de negocio llamado, por ejemplo, UserWithOthers con sólo las importantes propiedades (UserId, UserName, CityName, StateName, CountryName, List<Order>) y mi DAL recupera sólo que los campos de la Base de datos.

Caso 2

Quiero volver ahora a un usuario con la cantidad de pedidos, termino con los siguientes campos en mi objeto de negocio (UserId, UserName, CityName, StateName, CountryName, OrdersCount) y la clase podría ser llamado, por ejemplo, UserWithOrderCount

He pensado en algunas de las opciones:

1. Hacer que dos clases de negocios y relleno de ellos por separado en cada DAL método (este de los objetos son simples pero tenga en cuenta que el método puede tener una consulta de selección compleja que necesita ser encapsulados para su reutilización con el fin de repositorio patrón no encaja bien aquí, al menos creo que).
2. Crear un solo objeto User con todas las propiedades (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) y rellene sólo un subconjunto en cada DAL método, sino que implica la Semántica de Acoplamiento cuando se utiliza un método, porque usted debe saber que subconjunto de los campos se llenan de base de datos, y la semántica de acoplamiento es el peor de todos acoplamiento.
3. La opción 1 no manejar bien si necesito más tarde, en otra vista, tanto, List<Order> y OrdersCount propiedades.
4. Considere ahora que si uso ASP.NET MVC buenas prácticas dice que usted tiene un ViewModel para pasar a la vista, pensé para volver ViewModels de mi Negocio Capa, pero no creo que sea una buena idea, se siente como que estoy violando algo, y también no es posible porque mi capa de negocio es en otra asamblea y no de la aplicación web.
5. No quiero escribir la misma consulta Linq una y otra vez, pero si el uso o NHibernate EFCodeFirst es "como" opción uno, y voy a necesitar para crear toneladas de pequeños objetos de negocio.

¿Cómo manejar esta situación?Creo que este es un diseño de alto nivel de decisión.

Answer 1

Primero de todo, definitivamente estoy de acuerdo con usted sobre algunas cosas que no se hacer:

1. No parcialmente-rellenar objetos de negocio, como usted, a continuación, poner la responsabilidad de saber que propiedades están pobladas en la capa de negocio de los clientes, que es muy mala práctica.

2. No devolver el Viewmodel de la capa de negocio;la capa de negocio, se supone que representa los conceptos de negocio de la aplicación de su dominio, y un ViewModel es un objeto de datos que contiene los datos necesarios para mostrar una visión particular de una parte de ese dominio son dos cosas muy diferentes y la capa de negocio debe ser completamente inconsciente de que sus objetos de negocio se utilizan en cualquier tipo de interfaz gráfica.

Me gustaría ir con tu primera sugerencia de crear un objeto de negocio para representar a cada concepto de negocio.Me gustaría, a continuación, utilizar un ORM (como EF o NHibernate) para rellenar los objetos para mí, con Repositorios dedicados para cada grupo de objetos.Me gustaría a continuación, utilice una capa de aplicación que llama a los repositorios que devolver lo objetos son necesarios.a este fin su Repositorio puede incluir métodos que devuelven unió a los Usuarios y los Pedidos de los tiempos cuando usted sabe que usted necesita para tener esos dos tipos que se utilizan juntos.Esto le permite volver a un Usuario con todos sus Pedidos en una consulta, manteniendo separadas, significativa entidades que representan a los Usuarios y Pedidos.