Trabajo en una empresa que solo usa procedimientos almacenados para todo el acceso a datos, lo que hace que sea muy molesto mantener nuestras bases de datos locales sincronizadas como cada confirmación que tenemos para ejecutar nuevos procs. He usado algunos ORM básicos en el pasado y encuentro la experiencia mucho mejor y más limpia. Me gustaría sugerirle al gerente de desarrollo y al resto del equipo que analicemos el uso de un ORM de algún tipo para el desarrollo futuro (el resto del equipo solo está familiarizado con los procedimientos almacenados y nunca ha usado nada más). La arquitectura actual es .NET 3.5 escrita como .NET 1.1, con "clases de dios" que usan una implementación extraña de ActiveRecord y devuelven conjuntos de datos sin tipo que se agrupan en archivos de código subyacente; las clases funcionan de la siguiente manera:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...
Prácticamente no hay aplicación de ningún patrón de diseño. No hay pruebas de ningún tipo (nadie más sabe cómo escribir pruebas unitarias, y las pruebas se realizan cargando manualmente el sitio web y hurgando). Mirando a través de nuestra base de datos tenemos: 199 tablas, 13 vistas, 926 procedimientos almacenados y 93 funciones. Aproximadamente 30 tablas se usan para trabajos por lotes o cosas externas, el resto se usa en nuestra aplicación principal.
¿Vale la pena seguir un enfoque diferente en este escenario? Estoy hablando de avanzar solo porque no se nos permite refactorizar el código existente ya que "funciona", por lo que no podemos cambiar las clases existentes para usar un ORM, pero no sé con qué frecuencia agregamos módulos nuevos. de agregar / arreglar módulos actuales, así que no estoy seguro de si un ORM es el enfoque correcto (demasiado invertido en procedimientos almacenados y conjuntos de datos). Si es la elección correcta, ¿cómo debo presentar el caso para usar uno? Fuera de mi cabeza, los únicos beneficios que puedo pensar es tener un código más limpio (aunque podría no serlo, ya que la arquitectura actual no es t construido con ORM en mente, por lo que básicamente estaríamos instalando ORM con jurado en futuros módulos, pero los antiguos seguirían usando los DataSets) y menos problemas para recordar qué scripts de procedimiento se han ejecutado y cuáles deben ejecutarse, etc. pero eso es todo, y no sé cuán convincente sería un argumento. La mantenibilidad es otra preocupación, pero por la que nadie excepto yo parece estar preocupado.