¿Es mejor crear clases de modelo o seguir con la clase de utilidad de base de datos genérica?

Question

Tenemos una clase de utilidad simple interna para nuestras llamadas a la base de datos (un contenedor ligero alrededor de ADO.NET), pero estoy pensando en crear clases para cada base de datos/objeto. ¿Sería inteligente hacerlo o solo se beneficiaría si utilizáramos el marco completo de MVC para ASP.NET?

Así tenemos esto:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters); 
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters); 
SQLWrapper.Execute(connstr-alias, sql-statement, parameters); 

pensando en hacer esto:

Person p = Person.get(id); 
p.fname = "jon"; 
p.lname = "smith"; 
p.Save(); 

o para un nuevo récord -

Person p = new Person(); 
p.fname = "Jon"; 
p.lname = "Smith"; 
p.Save(); 
p.Delete(); 

¿Esto sería inteligente, o sería ¿excesivo? Puedo ver el beneficio de reutilización, cambio de base de datos y mantenimiento/legibilidad.

Answer 1

Se carga esta pregunta, diseño impulsado por datos frente a diseño impulsado por dominio. Para cualquier aplicación que tenga una buena cantidad de comportamiento, entonces se debe preferir el diseño impulsado por el dominio. Las aplicaciones de informes o de utilidad tienden a funcionar mejor (o son más rápidas de desarrollar) con un diseño basado en datos.

Lo que se pregunta es "si mi empresa realizara un cambio fundamental en la forma en que diseñamos nuestro código". Como un monstruo de dominio, mi reacción instintiva es gritar sí. Sin embargo, por la simple naturaleza de su pregunta, no estoy seguro de que entienda completamente el alcance del cambio que está proponiendo. Creo que deberías hablar más con tu equipo al respecto.

Obtenga un poco de literatura, como Evan's DDD libro, o el free foundations ebook, y entonces estará en una mejor posición para juzgar en qué dirección debe ir.

Answer 2

De ninguna manera MVC es el único patrón de diseño para la web, pero es útil.

Adoptar solo la 'M' pagará dividendos, en mi opinión, incluso si no puede/no adoptará la 'V' o la 'C'.

Answer 3

Para mí, parece que estás tratando de hacer lo que LINQ ya puede hacer por ti. Si está atascado en un marco anterior en el que no puede usarlo, le sugiero que use Subconic (http://subsonicproject.com/) en lugar de tener que crear manualmente todos estos objetos del modelo.

Tenía un proyecto en el que me encontraba en una situación similar y cambié a subsónico a la mitad con resultados fantásticos. Un desarrollo más rápido y MUCHO más fácil de leer/usar el código.

Answer 4

El enfoque que discuten es considerado uno bueno por mucha gente, ¡yo incluido! Aprender este enfoque requerirá un poco de esfuerzo, ¡pero no dejes que eso te desanime!

¿Qué tal si probamos un proyecto pequeño de con LINQ to SQL? Quizás encuentre un nice reference project en google code, y estudie cómo otros han trabajado con él.

Es una herramienta simple, y le permitirá familiarizarse con algunos de los problemas que surgen con la asignación de objetos a las bases de datos.

A continuación, podrá tener una idea de ello, y decidir si vale la pena la curva de aprendizaje.

Habrá nuevos conceptos para captar y experimentar con, cosas como:

• unidad de trabajo: Al ejecutar guardar y borrar etc, un ORM tiende a no hacer esto inmediatamente, mientras un conjunto de registros basado en DAL. Esto puede ser sorprendente, así que tendrás que aprender un poco sobre eso. Lea en el patrón de unidad de trabajo para obtener una comprensión de esto.
• Las operaciones masivas son un problema con OR/M. Un lector de datos puede iterar eficientemente a través de miles de filas, pero con un ORM debe tener cuidado al trabajar con grandes lotes de objetos. De nuevo, uno para leer.
• Las asociaciones parecen geniales cuando pueden hacer cosas como customer.Orders.Count pero también son la causa de muchos problemas. Tendrá que encontrar algunas prácticas seguras para seguir cuando trabaje con asociaciones.

... por nombrar algunos.

Para empezar, no se preocupe por la herencia y otras cosas, solo comience de manera simple y tenga entidades simples que se asocien a las tablas.

Intente utilizarlos de la misma manera que usaría su DAL existente. Luego comience a experimentar con asociaciones.

Entonces quizás trate de poner más comportamiento en sus entidades. Si comienza a gustarle esto y siente que necesita más funciones, considere probar un ORM más rico en características como Lightspeed o NHibernate.

Espero que esto ayude!