Должен ли я создать модель данных объекта ADO.NET для каждой таблицы или одну для всей моей базы данных?

Question

Предполагается ли использовать одну модель данных объекта ADO.NET для каждой таблицы? Или один для всей вашей базы данных, где также маршрутизируются отношения и т. Д ...

Answer 1

Сделайте это для всей базы данных. Если вы создадите модель данных для каждой таблицы, у вас не будет преимуществ в навигации по отношениям.

Если вы используете исходный контроль checkout / merge, такой как Subversion, имейте в виду, что разработчик использует XML до такой степени, что Subversion пытается его объединить. В этом случае вам обычно приходится каждый раз восстанавливать всю модель или объединять вручную.

Answer 2

Я использую модель данных сущностей для связанных таблиц. В зависимости от размера вашей базы данных я бы создал только одну модель, если бы было менее 20 или 25 таблиц. Создать отдельные модели для каждой таблицы немного дороже, потому что у каждой модели есть объект EntityConnection, который нужно создать.

Я считаю, что могу поддерживать модели достаточно хорошо, если у меня от 5 до 15 таблиц. Мой главный решающий фактор - это функциональность. Я строю инженерные приложения, поэтому, например, у меня есть около 6 таблиц компонентов из конструкционной стали. Они все в одной модели. Они имеют общие инженерные атрибуты, поэтому проще повторно использовать код, специфичный для манипулирования этими атрибутами.

Это означает, что я могу создавать экземпляры модели, создавать объекты, манипулировать / организовывать эти объекты в общем файле кода. Любые изменения, которые необходимо распространить обратно в базу данных, могут быть сделаны довольно эффективно.

Суть в том, чтобы определить ваши потребности и частоту использования для базовых объектов. Если вы собираетесь постоянно обновлять одну или две таблицы, то не имеет смысла иметь 30 других не связанных таблиц внутри этой модели. В этом сценарии, где часто используется небольшое количество таблиц, может иметь смысл создавать коллекции этих объектов, манипулировать коллекциями и обновлять базу данных в подходящее время.

Манипуляции с памятью намного дешевле, чем дисковые операции ввода-вывода. Это просто мой взгляд на рамки, и я ни в коем случае не являюсь экспертом в этом.

Answer 3

Один для всей вашей базы данных или хотя бы таблиц, которые вы будете использовать ...

Если у вас есть большое количество таблиц, вы можете разбить их на схемы или каким-то другим категориальным способом, но я бы сказал, что идея никогда не была моделью данных для каждой таблицы ...

Answer 4

Я разработал бы концептуальную / объектную модель данных независимо от схемы базы данных, а затем создал бы отображение, которое наилучшим образом связывает концептуальную модель со схемой базы данных. Может использовать большинство, если не все таблицы. Если вам нужно сопоставление таблиц «один к одному», вы можете вместо этого рассмотреть LINQ-to-SQL, поскольку с ним проще работать.

Answer 5

В дополнение к ответам выше, имейте в виду, что модель EF фактически находится на концептуальном уровне. Он не должен иметь ничего общего со структурой вашей базы данных и, конечно, не должен представлять всю базу данных.

Answer 6

Я думаю, что если у вас большая база данных, вам нужно классифицировать таблицы базы данных. Но вы должны создать класс для каждой таблицы, который является основным требованием структуры сущности ado.net.

Когда вы обновляете базу данных, вы можете обновить модель данных.

Сначала создайте базу данных, а затем создайте модель сущности ado.net.