tutorial net mvc framework first existing español code asp .net asp.net-mvc-3 entity-framework-4.1 ef-code-first ef-model-first

.net - net - entity framework tutorial español



Primer modelo EF o primer enfoque del código? (4)

Sé que esta pregunta se ha hecho muchas veces antes, ya que he leído bastantes publicaciones sobre el tema sobre los pros y los contras, etc., pero aún no puedo decidir cuál es el enfoque adecuado para mí. Soy muy nuevo en la programación web y procedo de un fondo de SQL DB Admin / informe de escritura. Decidí intentar construir mi propio sitio web, que puede terminar teniendo entre 30 y 40 tablas, tal vez más en el futuro.

Miré ambos enfoques y prefiero el enfoque del Modelo de Entidad solo porque me gusta la simplicidad del diseñador y me gusta ver todo el modelo frente a mí, muestra la imagen general en una instantánea. Además, al no ser un programador fuerte, estoy impresionado con la forma en que genera el POCO utilizando la plantilla del generador DbContext y hace todos los enlaces entre las clases.

Sin embargo, aunque me gusta el primer enfoque modelo, creo que hay algunos retrocesos, no estoy seguro de si son inconvenientes reales o simplemente no sé lo suficiente sobre el primer enfoque del modelo y el primer acercamiento del código, ya que todavía soy muy nuevo en esto.

Las razones por las que dudo en utilizar el enfoque Model First son:

-Principalmente porque estoy luchando por encontrar tutoriales sobre el primer acercamiento al Modelo usando MVC 3. El mejor tutorial que he encontrado usando el DbContext es por Julie Lerman, pero ella no cubre las clases de compañeros que son importantes para usar anotaciones de datos y hacer otras cambios que no se pierden cuando regenera las POCO. La mayoría de los tutoriales relacionados con MVC 3 parecen usar el primer enfoque del Código. La mayoría de la gente dice que esto se debe a que el tutor no quiere centrarse en EF sino que muestra más MVC en los tuts. Personalmente, creo que es porque Microsoft defiende la metodología Code First sobre los demás :)

-Si es una buena práctica crear clases de amigos ¿por qué no puedo encontrar muchos tutoriales que muestran esto para MVC 3? ¿Buddy Classes es otro nombre para View Models? ¿Y por qué no puedo encontrar ningún tutorial de Microsoft que muestre estos modelos de amigo / vista en uso con MVC 3?

-Intentaba hacer una relación básica de 1 a 1 entre 2 tablas. En el modelo primero, debe establecer las claves de identidad de cada tabla en el mismo campo en lugar de usar un FK en una de las tablas, lo que puede ser un poco confuso cuando tiene 3 o más tablas vinculadas entre sí por relaciones de 1 a 1. . Primero, en el código, una forma de evitar esto es utilizar el generador de modelos y configurarlo manualmente. Creo que en MF puedes cambiar la relación yendo al XML que no estoy interesado en hacer.

-Más soporte / ayuda en el primer código de problemas

Las razones por las que dudo en usar el enfoque de Code First son:

- Soy un codificador novato.

-Me parece cada vez más difícil hacer un seguimiento de las tablas y las relaciones a medida que el proyecto se expande.

-No hay un diagrama de modelo y tengo que decir que realmente me gusta esta idea.

-Mapeo de entidades a la base de datos a través de clases de configuración me parece imposible :).

-Actualizar una tabla requerirá un cambio en el código y la base de datos. En Model, primero solo hay un cambio en el modelo que actualizará automáticamente la base de datos y el código, y dijo que si está usando clases de amigos, puede que tenga que actualizarlas también.

También ahora veo que las personas combinan de alguna forma los primeros enfoques de Code First y Database, en el sentido de que no permite que Code First genere su base de datos, sino que crea manualmente una base de datos y utiliza el código API primero para EF para acceder a ella.

Mi cabeza está girando con todas las opciones y desventajas y pros y contras. Solo quiero seguir con la creación de mi sitio web y no reflexionar sobre qué enfoque tomar. ¿Alguien puede darme una idea de qué enfoque creen que se basa mejor en lo que he dicho y / o en lo que creen que será más flujo principal en el futuro?

Muchas gracias dave


Miré ambos enfoques y prefiero el enfoque del Modelo de Entidad solo porque me gusta la simplicidad del diseñador y me gusta ver todo el modelo frente a mí, muestra la imagen general en una instantánea. Además, al no ser un programador fuerte, estoy impresionado con la forma en que genera el POCO utilizando la plantilla del generador DbContext y hace todos los enlaces entre las clases.

+

Asignar entidades a la base de datos a través de clases de configuración me parece imposible :).

= usar modelo primero

Si es una buena práctica crear clases de amigos, ¿por qué no puedo encontrar muchos tutoriales que muestran esto para MVC 3? ¿Buddy Classes es otro nombre para View Models? ¿Y por qué no puedo encontrar ningún tutorial de Microsoft que muestre estos modelos de amigo / vista en uso con MVC 3?

Esto podría deberse a que primero el código es algo así como un niño nuevo en el bloque. Es por eso que en su mayoría hay un primer tutorial de código para MVC3. El modelo primero es ''mucho'' anterior y probablemente fue la solución más favorecida en tiempos de MVC2.

Por cierto: ya sabes mi opinión, que debes usar, lo que más te gusta o lo que más te gusta (como te dije la última vez que preguntaste sobre esto), pero solo quería agregar algo aquí :)

Editar después de los comentarios:

Echa un vistazo a estas cosas, que te ayudarán con el código primero muchísimo:

Creación de un modelo de datos de Entity Framework para una aplicación ASP.NET MVC (1 de 10) Andamio de su proyecto ASP.NET MVC 3 con el paquete MvcScaffolding

++ estos excelentes videos de MIX11 en channel9:
Scott Hanselman mostrando cosas nuevas en su manera increíble como generalmente
Steve Sanderson muestra el poder de MvcScaffolding


Es relativamente simple. Si no le importa el modelo de base de datos, primero use el código. Si lo hace, primero use Model (o Database First). Simplemente depende de dónde se encuentre su enfoque, centrado en los datos o centrado en el código.


Esta es una pregunta demasiado larga. Debe dividir su problema en varias preguntas por separado la próxima vez.

Código primero x Modelo primero x Base de datos primero

Usted es un tipo de base de datos, por lo que el mejor enfoque para usted es un primer enfoque de base de datos incremental en el que defina las cosas en DB (o herramientas de VS) y actualice su modelo desde la base de datos. Esto le dará un gran control sobre su base de datos y le permitirá construir la aplicación y la base de datos de forma incremental. Por qué creo que te gustará:

  • Ya hizo SQL DB Admin - probablemente sepa algo sobre DB y cómo diseñarlos para un rendimiento - EF no hará nada de esto por usted. EF no creará índices para ti, etc.
  • Las tablas de 30-40 significan que no se construirá el modelo en una sola toma. Comenzarás con el modelo pequeño y lo crecerás continuamente. Una vez que empiece a hacer cambios en la BD o agregue datos de inicialización, no querrá perder estos cambios y los datos. Code-first solo permite eliminar toda la base de datos y volver a crearla desde cero. El modelo primero permite construir la base de datos de forma incremental, pero necesita el paquete de generación de base de datos de Entity Designer y VS 2010 Premium o Ultimate ($ 5.000- $ 10.000).

Más acerca de las diferencias entre DB primero, Modelo primero y Código primero . Otra respuesta describe las diferencias entre el código primero y el trabajo con el diseñador .

DbContext API + Database-first + Flow mapping

Yo llamaría a esto la manera más difícil de ir. Primero definirá la base de datos y usará DbContext con la API o anotaciones de datos para definir la asignación. Esto requiere una buena comprensión de EF y todos los principios detrás del mapeo + comprensión de la convención predeterminada utilizada en DbContext API. Le dará un control agradable y explícito sobre el mapeo, pero es lo máximo que puede hacer. Definitivamente es la forma más difícil de ir. Tampoco se supone uso porque DbContext API se creó principalmente para el enfoque de primer código.

DbContext API x ObjectContext API

Una vez que comience a usar EDMX (diseñador de entidades), tiene la opción de utilizar la plantilla DbContext Generator T4 o la plantilla POCO Generator T4. La decisión depende de usted: puede usar DbContext API (primera plantilla) o ObjectContext API (segunda plantilla) que está mucho mejor documentada y también puede usar dos libros geniales:

Todo lo que sé sobre ObjectContext API es de estos libros, blogs de autores y práctica + Reflector.

DbContext API actualmente no tiene ningún libro. Puede consultar algunos sitios principales para obtener información al respecto:

Todo lo que sé sobre DbContext API es de estos blogs y práctica + Reflector.

Incluso si está usando el código primero, aún puede usar el diagrama de clases para visualizar su diagrama de clases (no es lo mismo que EDMX, pero es suficiente para obtener una idea general).

La búsqueda en o en el foro de MSDN le dará respuestas sobre la mayoría de los problemas que tendrá con ambas API.

MVC 3

No hay nada específico con el uso de Entity Framework con MVC 3. Las clases Buddy para anotaciones de validación de datos se consideran malas prácticas. Una clase buddy es una clase separada utilizada como un titular de metadatos aplicado en la entidad. Un modelo de vista es la clase utilizada para transferir datos entre el controlador y la vista. El modelo de vista debe ser específico por vista con sus propias anotaciones de validación porque generalmente necesita diferentes validaciones en diferentes pantallas de su aplicación cuando trabaja con el mismo tipo de entidad; por ejemplo, editar e insertar la pantalla puede tener diferentes requisitos de validación.

A pesar de que no se considera una buena práctica, es posible agregar validación a las entidades; puede crear clases de compañeros para cada entidad manualmente o puede intentar modificar la plantilla T4 para generar anotaciones directamente para usted (bueno, esto es difícil) .

Relación uno a uno

Sí EF requiere crear una relación de uno a uno solo sobre las teclas principales. La razón es que EF no admite claves / restricciones únicas. No hay forma de evitar esto y usar claves únicas en la base de datos no lo cambiará.


Puede usar los primeros ejemplos del modelo de cualquier versión de MVC, si ese es su problema principal con el modelo primero. La forma en que MVC maneja los "modelos" no es realmente diferente en todas las versiones. Claro, hay mejoras en el modelo de vista, etc., pero debería estar bien con los tutoriales más antiguos.

Prefiero el código primero, ya que creo que hay modelos de bases de datos y modelos de dominio que sirven para diferentes propósitos. La organización de la base de datos es para el rendimiento y el tamaño en la base de datos y no para ayudar a su aplicación. Tener su propio modelo le permite enfocarse en las necesidades del estado en su aplicación, independientemente de la base de datos.

Ahora, puede obtener este modelo del modelo primero, pero es más probable que piense en la base de datos de sus necesidades de esta manera ... esp. si eres un novato en esto.

Solo mis 2 centavos.