¿Debo crear un modelo de datos de entidad ADO.NET para cada tabla o uno para toda mi base de datos?

Question

¿Se supone que debe usar un modelo de datos de entidad ADO.NET para cada tabla? O uno para toda su base de datos donde las relaciones también se enrutan, etc ...

Answer 1

Hazlo para toda la base de datos. Si crea un modelo de datos para cada tabla, no tendrá la ventaja de navegar por las relaciones.

Si está utilizando el control de origen de verificación / fusión como Subversion, tenga en cuenta que el diseñador manipula el XML en la medida en que Subversion lucha por fusionarlo. En este caso, generalmente tiene que regenerar todo el modelo cada vez o fusionarlo a mano.

Answer 2

Utilizo un modelo de datos de entidad para tablas relacionadas. Dependiendo del tamaño de su base de datos, solo crearía un modelo si hubiera menos de 20 o 25 tablas. Es un poco costoso crear modelos individuales para cada tabla porque cada modelo tiene un objeto EntityConnection para crear.

Creo que puedo mantener los modelos bastante bien si tengo entre 5 y 15 tablas. Mi principal factor decisivo es la funcionalidad. Construyo aplicaciones de ingeniería, así que, por ejemplo, tengo alrededor de 6 tablas de componentes de acero estructural. Todos están en un modelo. Comparten atributos de ingeniería comunes, por lo que es más fácil reutilizar código específico para manipular esos atributos.

Esto significa que puedo crear una instancia del modelo, crear los objetos, manipular / organizar esos objetos dentro de un archivo de código común. Cualquier cambio que deba propagarse nuevamente a la base de datos puede realizarse de manera bastante eficiente.

La conclusión es determinar su necesidad y frecuencia de uso para los objetos subyacentes. Si va a actualizar constantemente una o dos tablas, entonces no tiene sentido tener otras 30 tablas no relacionadas dentro de ese modelo. En este escenario donde se usa con frecuencia una pequeña cantidad de tablas, podría tener sentido crear colecciones de estos objetos, manipular las colecciones y actualizar la base de datos en los momentos apropiados.

La manipulación de la memoria es mucho más barata de realizar que la E / S de disco. Esta es solo mi opinión sobre el marco y de ninguna manera soy un experto en él.

Answer 3

Uno para toda su base de datos o al menos las tablas que usará ...

Si tiene una gran cantidad de tablas, podría dividirlas en esquemas u otra forma categórica, pero diría que la idea nunca ha sido un modelo de datos por tabla ...

Answer 4

Diseñaría un modelo conceptual / objeto de los datos independientemente del esquema de la base de datos y luego crearía la asignación que mejor relacione el modelo conceptual con el esquema de la base de datos. Puede usar la mayoría de las tablas, si no todas. Si desea una asignación uno a uno a las tablas, puede considerar LINQ-to-SQL, ya que es más fácil trabajar con ellas.

Answer 5

Además de las respuestas anteriores, tenga en cuenta que un modelo EF está realmente en un nivel conceptual. No necesita tener nada que ver con la estructura de su base de datos, y ciertamente no necesita representar la base de datos completa.

Answer 6

Creo que si tiene una base de datos grande, entonces necesita clasificar las tablas de la base de datos. Pero debe crear una clase para cada tabla que sea un requisito principal del marco de entidad ado.net.

Cuando actualiza la base de datos, puede hacerlo con el modelo de datos de actualización.

Primero diseñe su base de datos y luego cree el modelo de entidad ado.net.