¿CodeFirst está destinado a aplicaciones a gran escala?

He estado leyendo sobre Entity Framework, en particular, EF 4.1 y siguiendo este enlace ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) y su guía sobre Code First.

Me parece ordenado, pero me preguntaba, ¿se supone que Code First es solo una solución para un desarrollo rápido en el que puede saltar directamente sin mucha planificación o realmente está destinado a ser utilizado para aplicaciones a gran escala?

Es posible que tenga algunos detractores, pero cuando leí algunas de esas publicaciones de Hanselman y Gutherie, luego leí el libro de Julia Lerman sobre Entity Framework, tuve un REALMENTE difícil con el código primero. En mis muchos años de creación de aplicaciones, he recorrido muchos caminos, tanto forzados por el proceso como por elección, y he descubierto que tengo mucho más éxito al tomar una vista centrada en los datos al crear una aplicación.

Estoy hablando de aplicaciones de línea de negocios aquí ... esto es cuando tienes un problema o proceso de negocios que necesita tener una solución de software detrás. Tiene datos que necesita gestionarse de alguna manera. Es mejor conocer sus datos y cómo se relacionan consigo mismos y cómo se utilizan dentro de la empresa. Por lo tanto, modela esos datos y luego crea una aplicación / solución a su alrededor. En mi experiencia, si comienzas a crear la aplicación con los datos como una ocurrencia tardía, algo eventualmente se queda fuera, y luego tienes algo de refactorización (en muchos casos, refactorización MAYOR).

Las aplicaciones pequeñas pueden ser una excepción, pero continuaré usando mi enfoque centrado en los datos.

No veo por qué CodeFirst no se puede utilizar en grandes proyectos empresariales. Diré que uso EF CodeFirst en varios proyectos, uno donde la base de datos es generada por mi modelo EF CodeFirst y el segundo donde EF CodeFirst se asigna a una base de datos existente.

Según mi experiencia, la efectividad de la CF en un gran proyecto depende en gran medida de cuán abstraída sea su capa de datos de su capa empresarial.

Por ejemplo, en uno de mis proyectos, la capa empresarial llama directamente a la base de datos a través de linq. Uso Linq para abstraer la capa de mi base de datos y uso CodeFirst para asignar mis POCO en el esquema de la base de datos. En este caso, CodeFirst hace que el acto de mantener las diferencias entre las convenciones de DB (nombres de relaciones y tablas) y mis nombres de clase C # sea mucho más simple, y puedo hacer cambios en la base de datos sin tener que afectar en gran medida la forma en que mi capa empresarial interactúa con la base de datos.

Sin embargo, en otro proyecto, abstraje el acceso a la base de datos en un patrón de repositorio no genérico, y los métodos Get * de mi repositorio son los únicos responsables de ejecutar consultas en la base de datos, y devuelven objetos reales (no IQueryable<T>s). En este caso, los métodos de repositorio están convirtiendo entidades DB en entidades POCO y, en este caso, CodeFirst no le proporciona tantos beneficios como las POCO de CodeFirst son de corta duración y se convierten rápidamente en clases de capa empresarial C #.

En última instancia, realmente depende de cómo esté estructurado el equipo y qué tan cómodo esté el equipo (o las personas de la tercera edad) con los ingenieros que no son DBA que modifican los esquemas de la base de datos, y cuántos cambios de esquema afectarán su estructura de código. Con CodeFirst asignado a una base de datos existente, es trivial para mí reasignar una propiedad a un nuevo nombre de columna sin tener que cambiar el nombre global de ese nombre de propiedad, lo que es especialmente un factor cuando se habla de un nombre que tiene más sentido para un campo de base de datos en lugar de una propiedad C #. También es trivial para mí agregar soporte de código para nuevos campos de base de datos sin tener que remodelar completamente mis entidades C # (una de las razones por las que dejé Linq-to-sql a EF CodeFirst desde una base de datos existente).

Code First no es adecuado para aplicaciones a gran escala. El cambio en el desarrollo de aplicaciones a gran escala es muy grande.

Por lo general, el ciclo de vida de su aplicación comercial es,

1. La versión 1 está en producción.
2. La versión 2 está en beta
3. La versión 3 está en desarrollo activo
4. La versión 4 está en planificación.

Y hay otros puentes de comunicación entre aplicaciones, algunas tareas programadas, alguna integración de terceros, servicios web para algunos dispositivos de comunicación diferentes, como dispositivos móviles, etc.

Finalmente, Code First usa ObjectContext de Entity Model, EF más antiguo que genera EDMX y usar ObjectContext con EntityObject fue realmente suficiente para todo. Puede personalizar fácilmente la plantilla de texto para generar código. El método de detección de cambios es más lento con la implementación de ObjectContext, pero en lugar de generar proxy, el equipo de EF podría haber mejorado fácilmente la velocidad de detección de cambios en lugar de reinventar el código primero.

Migración Automatizada

La migración automatizada suena bien en teoría, pero imposible en la práctica una vez que se pone en marcha. Solo es bueno para la creación de prototipos, desarrollando algunas demostraciones rápidas.

Code First Migration no es en absoluto adecuado en dicho sistema. La versión 1 y la versión 2 probablemente hablan con la misma base de datos. La versión 3 y la versión 4 suelen estar preparadas y tienen una base de datos diferente.

Base de datos primero

Database First es un enfoque práctico, es fácil de comparar, visualizar y mantener secuencias de comandos SQL. Los DBA pueden trabajar fácilmente.

Plantillas de texto

Creamos nuestras propias plantillas de texto para consultar y crear EDMX y ObjectContext con poca implementación personalizada que aborde problemas de rendimiento. Existen múltiples aplicaciones con múltiples versiones que se comunican a la misma base de datos sin ningún problema.

Para mí, hacer clic derecho en el archivo .tt y hacer clic en "Ejecutar herramienta personalizada" es, con mucho, el paso más rápido y fácil que escribir clases, configurar y crear modelos.

Por lo general, para proyectos grandes, la base de datos ya se ha creado. Ya sea porque es una base de datos heredada o creada por un dba competente para el rendimiento. El único beneficio de CodeFirst es si no desea utilizar las entidades de EF, sino POCO.

Me parece que "Code First" está diseñado para usar EF con más "agile" (no insista demasiado en ese término, no necesariamente me refiero a la metodología) y aplicaciones greenfield, donde no tiene un modelo de datos existente o datos existentes; el tipo de aplicación que también podría usar Django, o un marco PHP, o Rails para seguir las pautas de esos marcos que normalmente implican crear el modelo de datos como parte del código, en lugar de crear una aplicación alrededor de un modelo de datos que es el tradicional Manera de Microsoft de manejar las cosas.

Entonces, para responder la pregunta, diría que no; si ya tiene datos existentes y está creando una aplicación para manejarlos, Code First no tiene tanto sentido. Sin embargo, y no he usado mucho EF, y mucho menos Code First EF, parece que es un enfoque de código más flexible que siempre es beneficioso. Suponiendo que puede usar Code First y luego seguir apuntando la clase a un modelo de datos existente (en lugar de verse obligado a generar el modelo), el enfoque de Code First podría ayudar a escribir código correctamente resumido y comprobable sin todo el "cruft" habitual de usar Entity Framework (es decir, las metaclases generadas).

Yo diría que en proyectos realmente grandes, el código primero no tiene sentido.

De hecho, cuando el proyecto se hace realmente grande, a menudo tiene una separación estricta de preocupaciones. No puedes tener a la misma persona escribiendo código C #, haciendo diseño de bases de datos, escribiendo HTML / CSS y haciendo diseño visual en Photoshop. En cambio, el diseño de la base de datos lo realiza un administrador de la base de datos (o al menos una persona dedicada que conoce su trabajo).

Dado que la base de datos está diseñada por una persona que está familiarizada con la base de datos, SQL y las herramientas de administración y diseño de bases de datos, sería extraño ver a esta persona usando Entity Framework.

Además, no estoy seguro de si Entity Framework es lo suficientemente potente como para diseñar la base de datos correctamente. ¿Qué pasa con los índices? Restricciones? ¿Puntos de vista?

El código primero es viable incluso para sistemas grandes: simplemente examine el modelo después de la creación y vuelva a asignar usando la API fluida hasta llegar a un modelo db que le guste.