¿Escribir su propia capa de acceso a datos / mapeo de datos es una "buena" idea?

Actualmente nos encontramos en una situación en la que tenemos que elegir entre usar un mapeador relacional de objetos listo para usar o rodar el nuestro

Tenemos una aplicación heredada (ASP.NET + SQL Server) donde la capa de datos y la capa de negocios desafortunadamente se unen. El sistema no es particularmente complicado en términos de acceso a datos. Lee datos de un gran grupo (35-40) de tablas interrelacionadas, las manipula en la memoria y las guarda en otras tablas en un formato de resumen. Ahora tenemos la oportunidad de refactorizar y estamos buscando tecnologías candidatas para usar para separar y estructurar adecuadamente nuestro acceso a datos.

Independientemente de la tecnología que decidamos, nos gustaría:

• tener objetos POCO en nuestro modelo de dominio que son ignorantes de persistencia
• tener una capa de abstracción que nos permita realizar pruebas unitarias de nuestros objetos de modelo de dominio contra una fuente de datos subyacente simulada

Obviamente, hay muchas cosas sobre esto en términos de patrones y marcos, etc.

Personalmente, estoy presionando para que use EF junto con el Generador de repositorios comprobables de unidades ADO.NET / Generador de entidades POCO . Satisface todos nuestros requisitos, se puede agrupar fácilmente dentro de un patrón Repo / UnitOfWork y nuestra estructura de base de datos es razonablemente madura (ya se ha sometido a un refactorizador) de modo que no haremos cambios diarios al modelo.

Sin embargo, otros en el grupo están sugiriendo diseñar / rodar nuestro propio DAL completamente desde cero. (Custom DataMappers, DataContexts, Repository, Interfaces en todas partes, Inyección de dependencia exagerada para crear objetos concretos, Traducción personalizada de consultas de LINQ a subyacente, Implementaciones de almacenamiento en caché personalizadas, Implementaciones de FetchPlan personalizadas ...) la lista continúa y, para ser franco, son huelgas yo como locura

Algunos de los argumentos planteados son "Bueno, al menos estaremos en control de nuestro propio código" o "Oh, he usado L2S / EF en un proyecto anterior y no fue más que dolores de cabeza". (Aunque he usado ambos en Producción anteriormente y he encontrado que algunos problemas son pocos y distantes entre sí, y muy manejables)

Entonces, ¿alguno de sus desarrolladores / arquitectos súper experimentados tiene alguna palabra de sabiduría que pueda ayudarme a alejar este producto de lo que me parece que va a ser un completo desastre? No puedo evitar pensar que cualquier beneficio obtenido al esquivar los problemas de EF se perderá con la misma rapidez al intentar reinventar la rueda.

Ambos argumentos contra ORM existentes no son válidos:

"Bueno, al menos estaremos en control de nuestro propio código"

¿Por qué no escribes tu propio idioma? ¿Tu propio marco? ¿Tu propio sistema operativo? Y para asegurarse de que tiene el control de todo, también es una buena idea crear su propio hardware.

"Oh, he usado L2S / EF en un proyecto anterior y no fue más que dolores de cabeza"

EF es lo suficientemente maduro y fue utilizado con éxito por muchas personas. Significa que una persona que afirma que EF no es más que un dolor de cabeza probablemente debería comenzar a aprender a usar EF correctamente.

Entonces, ¿tienes que escribir tu propio ORM?

Yo no sugeriría eso. Ya hay ORM de nivel profesional, lo que significa que debe escribir los suyos solo si:

• Tiene un contexto preciso donde todos los ORM existentes no pueden ajustarse por alguna razón,
• Está seguro de que el costo de crear y usar su propio ORM en lugar de aprender uno existente es mucho menor. Esto incluye el costo del soporte futuro, incluido otro equipo de desarrolladores que tendría que leer cientos de páginas de su documentación técnica para comprender cómo trabajar con su ORM.

Por supuesto, nada le prohíbe escribir su propio ORM solo por curiosidad, para aprender cosas. Pero no debes hacerlo en un proyecto comercial.

Vea también los puntos 2 a 3 de mi respuesta a la pregunta Reinventar la rueda y NO arrepentirse. Puede ver que las diferentes razones para reinventar la rueda no se aplican aquí.

Use Entity Framework para todas las cosas CRUD ordinarias (80 a 95 por ciento del código), y use código de acceso a datos personalizado para cualquier código restante que necesite ser optimizado. Esto debería satisfacer las preocupaciones de aquellos que argumentan que no tienes suficiente control.

Es una buena idea si y solo si puede estar (al menos razonablemente) seguro de que ahorrará al menos tanto tiempo / esfuerzo escribiendo su propio código como se necesita para generar ese código en primer lugar. Dependiendo de la situación, hacerlo también puede afectar su horario, y tendrá que tenerlo en cuenta también. También debe incluir el mantenimiento a largo plazo en la ecuación. Si lanza su propio ORM, deberá mantenerlo para siempre (o al menos mientras lo use).

La conclusión es que puede tener sentido, en las condiciones adecuadas. Estas condiciones generalmente incluyen:

1. El proyecto en el que está trabajando es bastante grande, por lo que el costo se amortiza con una gran cantidad de uso.
2. Su uso de datos es lo suficientemente inusual como para que las bibliotecas existentes (y demás) funcionen bastante mal para sus propósitos.

A riesgo de afirmar lo obvio, estos dos están inversamente relacionados: si está trabajando en un proyecto realmente gigantesco, incluso un pequeño ahorro en cada uso individual puede sumar lo suficiente para justificar el desarrollo. Por el contrario, si sus necesidades son realmente inusuales, por lo que gana mucho en cada uso, el trabajo puede justificarse incluso en un proyecto bastante pequeño.

Sin embargo, al menos según su descripción, ninguno de los dos se aplica realmente en su caso. Tal vez uno (o incluso ambos) se aplicó al uso anterior de EF por parte de su compañero de trabajo, o tal vez solo tiene prejuicios: no creo que nos haya brindado suficiente información para siquiera adivinar qué (aunque para ser justos, debo agregar que yo ' Supongo que es porque no te ha dicho lo suficiente como para adivinar).

Si estuviera a cargo de esta situación, creo que haría que usted y sus compañeros de trabajo escribieran una especie de documento de posición: una lista de fortalezas y debilidades que ve con cada enfoque, junto con evidencia real para respaldar cada afirmación / reclamo /lo que sea. Luego, todo el equipo llegaría (es decir, estaría obligado a) criticar cada artículo. El punto principal en su crítica sería calificar cada punto en dos escalas:

1. el grado en que el punto parece exacto, bien respaldado por hechos, etc., y
2. El grado en que el punto parece aplicarse al proyecto en cuestión.

Luego evaluaría los documentos y las críticas para llegar a una decisión (aunque siendo completamente honesto, podría ser difícil decir cuánto los estaba usando para tomar la decisión y cuánto los estaba usando para justificar una decisión). Ya lo había hecho, sé que probablemente no debería admitir eso, pero la realidad es que yo también soy humano ...)

Editar:

Si quisiera ser particularmente desagradable (o "educativo", difícil de distinguir en este caso), quisiera que cada uno de ustedes intente desarrollar una estimación del esfuerzo de desarrollo general utilizando un ORM / DAL existente y desarrollando tu propio. Aunque es solo una suposición, mi suposición inmediata es que la mayoría de las personas con grandes planes para desarrollar las suyas no se molestarían en entregar sus estimaciones, para cuando llegaron a una estimación del esfuerzo general que incluso se terminó de forma remota (y realista), se darían cuenta de que no había manera de que pudieran acercarse a competir con el uso del código existente. Al mismo tiempo, '

Edición 2: (más o menos en la sugerencia de @ CmdKey): Aunque no se menciona explícitamente, supongo que una estimación incluirá implícitamente una evaluación de riesgo. En particular, una estimación del tiempo normalmente debe incluir números de estilo PERT:

1. La mejor estimación del caso más rápido se podría hacer si todo saliera bien.
2. La estimación "normal": cuánto tiempo espera que tome.
3. La estimación del peor de los casos más larga que podría tomar si todo saliera mal.

Por supuesto, las estimaciones del mejor y el peor de los casos normalmente no deberían incluir cosas como la intervención divina directa, sino que deberían incluir casi cualquier cosa menos que eso.

Por lo general, nunca es una buena idea reinventar la rueda, y hacerlo suele ser una indicación de ignorancia técnica ("No sé nada más y no quiero aprender") o arrogancia ("X es estúpido, puedo escribir mi propia herramienta en dos semanas! "); Existen herramientas maduras que pueden hacer las cosas mucho mejor de lo que algunos desarrolladores promedio pueden hackear en pocas semanas.

Dicho esto, sin embargo, hay momentos en los que no se puede ajustar de manera confiable una aplicación heredada alrededor de una solución existente (sin importar cuán flexible sea) sin una tonelada de trabajo; en un caso como este no es una "buena" idea, sino una mejor idea que las alternativas (es decir, dejarla como está o reescribir la mitad para poder usar la capa de terceros), por lo que tiene pocas opciones.

Estaba en un proyecto que rechazó las herramientas Java ORM existentes para escribir las suyas propias, debido a alguna característica "crítica" que no estaba presente en Hibernate. Este fue un error multimillonario y el costo aumenta a diario. Todavía no tienen soporte completo para las relaciones de objeto. Por lo tanto, además de todo el tiempo dedicado a crear y mantener el marco, pasan horas escribiendo código que podría escribirse en minutos usando Hibernate, o en muchos casos no necesitaría escribirse en absoluto.

Los marcos existentes son producto de decenas de años-hombre de esfuerzo. Es absurdamente ingenuo imaginar que un solo equipo podría acercarse en unas pocas semanas hombre.

El código que debe escribir es el código que debe mantener. El tiempo dedicado a mantener el código ORM es el tiempo dedicado a no mantener la aplicación. A menos que el ORM le brinde algún tipo de ventaja estratégica, entonces no es algo que genere dinero para el negocio, por lo que es pura sobrecarga. ¿Preferiría su empresa gastar dinero en gastos generales o mejorar un producto para hacer dinero? Si esto es para una aplicación interna, entonces esto puede no ser un problema, pero todavía está aumentando la cantidad de código que deberá escribirse, probarse y documentarse.

Diría que desplegar su propio ORM es una MALA idea, a menos que tenga una muy, muy buena razón para hacerlo (por cierto, las que citó no son lo suficientemente buenas :)

Una vez cometí un error al hacer que otros me convencieran de no usar ORM y puedo decirles que escribir todos los DAL nosotros mismos realmente nos retrasó y, en lugar de implementar características que importaban para los negocios, pasábamos tiempo en DAL (es mucho más trabajo de lo que parece).

El nuevo EF parece ser bastante bueno, pero si quieres tener más control, habría buscado en micro ORM / s como: Drapper http://code.google.com/p/dapper-dot-net/ o PetaPOCO http : //www.toptensoftware.com/petapoco/

También puede mezclar y combinar: use EF para la mayor parte de las cosas y Drapper para un ajuste fino.

De todos modos eso es solo mi 2c;)