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

votos
5

Tenemos una clase de utilidad simple interna para nuestras llamadas a la base de datos (un contenedor de luz 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?

Entonces 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 registro -

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

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

Publicado el 05/08/2008 a las 21:10
fuente por usuario
En otros idiomas...                            


4 respuestas

votos
8

Esta pregunta es cargada, diseño impulsado por datos vs 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 está preguntando es "¿debería mi empresa hacer un cambio fundamental en la forma en que diseñamos nuestro código?". Como un monstruo de dominio, mi reacción visceral es gritar . 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 el libro DDD de Evan , o el libro electrónico de fundaciones gratuitas , y entonces estará en una mejor posición para juzgar en qué dirección debe ir.

Respondida el 05/08/2008 a las 21:28
fuente por usuario

votos
2

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

¿Qué tal si probamos un pequeño proyecto con LINQ to SQL ? Tal vez encuentre un buen proyecto de referencia en el código de Google 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.

Luego podrá hacerse una idea y decidir si vale la pena la curva de aprendizaje.

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

  • Unidad de trabajo : cuando ejecuta Guardar y Eliminar, etc., un ORM tiende a no hacer esto inmediatamente, mientras que un DAL basado en el conjunto de registros lo hará. Esto puede ser sorprendente, así que tendrás que aprender un poco sobre eso. Lea sobre el patrón de unidad de trabajo para comprender 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 ser geniales cuando pueden hacer cosas similares, customer.Orders.Countpero también son la causa de muchos problemas. Tendrá que encontrar algunas prácticas seguras para seguir cuando trabaje con asociaciones.

...para nombrar unos pocos.

Para empezar, no te preocupes por la herencia y otras cosas, simplemente comienza de manera simple y tienes entidades simples que se asignan a las tablas.

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

Entonces quizás intente 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!

Respondida el 03/10/2008 a las 11:07
fuente por usuario

votos
2

De ninguna manera es MVC 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'.

Respondida el 05/08/2008 a las 21:13
fuente por usuario

votos
0

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

Tuve 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.

Respondida el 26/09/2008 a las 15:41
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more