Hemos estado teniendo una discusión en el trabajo sobre si usar Objetos de dominio en nuestras vistas (asp.net mvc 2) o si cada vista que requiere datos debe enviarse un ViewModel?Objeto de dominio en Vistas
Me preguntaba si alguien tenía algún pros/contras sobre este tema que pudieran arrojar algo de luz sobre?
Gracias
me gusta separar mis objetos de dominio de mis puntos de vista. En lo que a mí respecta, mis objetos de dominio son únicamente con el propósito de representar el dominio de la aplicación, ahora cómo se muestra la aplicación.
La capa de presentación no debe contener ninguna lógica de dominio. Todo lo que muestran debe ser predeterminado por su controlador. La forma ideal de garantizar que esto siempre se cumpla es garantizar que la vista solo reciba estos ViewModels aplanados.
Hice una pregunta yo similar question. He aquí una cita de la respuesta acepté:
Creo que hay méritos a que tienen un diseño diferente en el dominio que en la capa de presentación. Así que, en realidad, en realidad es mirando dos modelos diferentes, uno para la capa de dominio y otro para la capa de presentación . Cada uno de los modelos está optimizado para su propósito.
Si tengo los objetos de dominio para Customer>Sales>Dispatch Address, entonces yo no quiero tener que lidiar con el objeto de recorrido en mi opinión. Creo un modelo de vista aplanada que contiene todas las propiedades. Casi no hay trabajo adicional en el mapeo hacia y desde este modelo de vista/presentación aplanado si utiliza el excelente proyecto de código abierto AutoMapper.
Además, ¿por qué quiere pasar todo un objeto de dominio de nuevo a una vista si se puede crear un optimizado representación de ese modelo?
Si utiliza NHibernate o similar - los objetos de dominio probablemente será proxies, la serialización de estos trabajos Dun. Siempre debe usar un ViewModel y asignar sus objetos de dominio a DTO dentro de su viewmodel. No tome atajos aquí. Establecer la convención aliviará el dolor que sufrirá más adelante.
Es un patrón estándar por un motivo.
w: //
Depende. En algún caso, estará bien usar instancias de clases modelo. En otros casos, un ViewModel por separado es la mejor opción. En mi experiencia, es perfectamente aceptable tener diferentes modelos en su dominio y en sus puntos de vista. O para usar el modelo de dominio en la vista. Haz lo que funcione mejor para ti. Haga un pico para cada opción, vea lo que funciona y luego decida. Incluso puede elegir una opción diferente para cada vista (y/o parcial).
Definitivamente van a ser pequeñas aplicaciones simples donde está bien usar los mismos modelos en todas las capas. Generalmente formas pequeñas sobre las aplicaciones de datos. Pero para un dominio adecuado, mis pensamientos sobre el tema son mantener los modelos de dominio y ver los modelos separados porque no quiere que se impacten entre sí cuando se modifican.
Si la lógica de dominio necesita un pequeño cambio para procesar alguna nueva lógica de negocios en el back-end, no quiere arriesgarse a que se altere su vista. Por el contrario, si el marketing o alguien desea realizar cambios en una vista, no desea que esos cambios se filtren nuevamente a su dominio (tener que rellenar campos y mantener los datos para otro fin que no sea el de alguna vista que vaya a usarlo).
Actualmente tengo una buena comparación porque estoy trabajando en dos proyectos usando diferentes enfoques. Estoy lejos de afirmar que "esto es malo y esto es bueno" porque está escrito en algunos patrones. Conozco patrones, me gustan los patrones, pero nunca los sigo ciegamente para estar en lo cierto. Siempre uso lo que necesito actualmente para alcanzar los objetivos actuales.
En la primera aplicación, usando objetos de dominio a la vista, el desarrollo es muy rápido. Pocos cambios en pocos lugares y usted tiene propiedades adicionales, entradas de formularios, etc. No se preocupa por las capas, solo extiende/cambia el código y pasa a otro problema.
En la segunda aplicación, donde siempre hay un objeto para usar aquí, allí y en otro lugar, hay docenas de clases con el mismo aspecto, haciendo lo mismo y un montón de código de conversión entre varias versiones de los mismos objetos. Más malo es que algunos desarrolladores hacen algo de lógica en "esta versión" de clase, y otra lógica se hace en "esa versión". El desarrollo es muy doloroso y requiere una gran cantidad de pruebas después. Cambiar algo simple requiere mucha atención y es necesario cambiar mucho código. Realmente no me gusta esta aplicación porque todavía no he visto beneficios comerciales de este enfoque, al menos durante el año pasado (y estamos en la etapa de producción del año). Esta aplicación es tres-cuatro veces más costosa de desarrollar y mantener que la primera.
Por lo tanto, mi respuesta divertida sobre la pregunta es: depende. Si trabajas en equipo de 10 a 20 personas, te gusta venir al trabajo, tomar algunas cafeterías, hablar con un amigo, hacer algunas cosas simples e ir a casa, una gran cantidad de objetos intermedios y el código de conversión serán buenos para ti. Si tu objetivo es ser rápido y barato, si quieres enfocarte en la capa de negocios, nuevas funciones, cambios rápidos y mucho más si tocas el negocio del software y quieres cobrar tu proyecto (hacemos todo esto para finalmente venderlo, ¿verdad?), el segundo enfoque sería probablemente mejor.
+1, pero ¿qué pasa con objetos de dominio simple, como una Categoría, que solo tiene Id y etiqueta? Para algunas aplicaciones con muchos de estos, puede ser bastante molesto crear MyEntity {Id, Label} y MyDto {Id, Label}, donde lo único que difiere es el nombre. – mathieu
@mathieu - Obviamente puedes usar tu discreción cuando se trata de ejemplos como este :). Los objetos de dominio como su ejemplo no contendrían ninguna lógica de dominio y, por lo tanto, serían aceptables. – GenericTypeTea
bien eso es lo que pensé. si tiene algo de tiempo, ¿podría echarle un vistazo a este: http://stackoverflow.com/questions/3539108/asp-net-mvc-model-inheritance? No soy realmente nuevo con las cosas técnicas de asp.net mvc, pero para el diseño "filosófico", ¡podría usar algunos consejos! – mathieu