Автономные модульные классы с использованием Microsoft Entity Framework / Linq to SQL

Question

Я использую .NET 2 для веб-программирования в течение нескольких лет (из-за ограниченной поддержки, которую мы имеем для всего остального на серверах, которые мы используем), но недавно начал изучать использование .NET 4 для некоторых новых проекты.

В рамках этого я пытался научиться использовать Microsoft Entity Framework / Linq to SQL. Кажется, что это делает основы очень простыми, и вы можете собрать полностью функциональный класс в кратчайшие сроки. Тем не менее, теперь я начинаю продвигать это немного дальше, я нахожу проблемы, которые я не знаю, как обойти.

Одна из вещей, которая меня беспокоит, это то, что я не понимаю, как организовать вещи. Очевидно, я привык хранить связанные классы в пространствах имен, и, как правило, эти пространства имен отражают структуру базы данных (например, пространства имен сопоставляются с префиксами имен таблиц). Используя EF, кажется, что каждый из моих классов должен находиться в одном и том же пространстве имен. Конечно, у меня может быть несколько контекстов данных в отдельных пространствах имен, но тогда я теряю преимущества, которые предлагает EF, поскольку классы больше не имеют никакого отношения друг к другу. Я могу жить с этим, но мне кажется, что я что-то упускаю?

Другая проблема, которая у меня возникает, которая беспокоит меня еще больше, это то, что я привык создавать автономные модульные классы, и я не понимаю, как это возможно с EF. Например, я не могу понять, как написать простую функцию Save, потому что если вы вызываете db.SaveChanges (), то сохраняются изменения всей базы данных - и если вы вызываете mySingleObject.Save (), то это не ' Это кажется желательным, так как это также сохранит изменения в любых других объектах, с которыми вы случайно возились. Учитывая, что я встраиваю эту функциональность в библиотеку классов, необходимость вызова db.SaveChanges () из-за пределов библиотеки классов также кажется сумасшедшей, потому что все, что находится за пределами моей библиотеки классов, не должно требовать каких-либо знаний о том, как хранятся мои данные.

Я упускаю из этого суть или мне нужно изменить свое мышление?

В настоящее время я изо всех сил пытаюсь продвинуть свой проект из-за этих проблем, и я собираюсь вернуться к простому старому SQL. Это было бы позором, потому что у EF явно есть некоторые огромные преимущества, и я хотел бы максимально использовать это!

Answer 1

У меня никогда не возникало проблем с необходимостью хранить все объекты моей базы данных в одном пространстве имен. Я не думаю, что очевидно, что можно было бы создать пространства имен, которые так или иначе связаны с базой данных. Я думаю, что это создает тесную связь, которую лучше всего избегать вместе, в частности, ваше приложение не должно заботиться о схеме основного хранилища данных. Я думаю, что пространства имен обычно используются для группировки (и области действия) логических объектов - то есть всех классов, связанных с ведением журнала, или, в этом случае, всех классов, связанных с взаимодействием с хранилищем постоянства.

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

Как правило, шаблон активной записи одного класса, представляющего строку в базе данных, выходит из строя и шаблон репозитория ( предыдущий вопрос , msdn *) 1010 *) занимает его место.