Линк к сущностям и бизнес-логике

Модель объекта создает частичные классы. В моем проекте я использую модель сущностей внутри библиотеки классов и добавляю к ней несколько файлов .cs, которые добавляют функциональность к классам сущностей по умолчанию. (В основном это функции, связанные с регистрацией ошибок и сообщений в таблице базы данных и методом импорта/экспорта всех данных в XML.)

Но настоящая бизнес-логика находится во второй библиотеке классов, которая ссылается на эту библиотеку классов сущностей.

---

Поясним. Сначала я создал модель объекта из базы данных. Он содержит список названий компаний и адресов. Я делаю это, выбирая «Новый проект | Библиотека классов», а затем добавляю модель данных объекта ADO.NET в эту библиотеку. Модель Entity будет связана с моей базой данных SQL Server, импортирует нужные мне таблицы и автоматически создает классы для таблиц, к которым я хочу получить доступ. Затем я добавляю второй файл .cs для каждой таблицы, которую я хочу расширить. Это будет несколько необработанных методов, тесно связанных с базой данных. (В основном методы импорта/экспорта и ведение журнала ошибок.) Это я вызову Entity.Model, который будет скомпилирован в Entity.Model.dll.

Затем я добавляю второй проект, который будет содержать бизнес-логику. Опять же, я использую «Новый проект | Библиотека классов», чтобы создать его и добавить Entity.Model.dll к его ссылкам. Затем я начинаю писать классы, которые преобразуют классы, специфичные для базы данных, в более логические классы. В общем, мне не пришлось бы вносить много изменений, за исключением того, что я буду защищать или скрывать определенные поля и добавлять несколько вычисляемых полей. Бизнес-логика будет раскрывать только те функции, к которым я хочу получить доступ из моего клиентского приложения, и ни один метод больше. Таким образом, если я не позволю клиенту удалять компании, функция «Удалить» в модели объекта не будет доступна на бизнес-уровне. И, может быть, я хочу отправить уведомление, когда компания меняет свой адрес, поэтому я добавлю событие, которое срабатывает при изменении поля адреса компании. (Что будет писать журнал сообщений или что-то еще.) Я назову это business.logic, и он скомпилируется в Business.Logic.dll.

Наконец, я создам клиентское приложение и добавлю ссылку на Business.Logic.dll. (Но НЕ к модели объекта.) Теперь я могу начать писать свое приложение и получать доступ к базе данных через бизнес-уровень. Бизнес-уровень будет выполнять проверки, запускать несколько событий и делать что-либо еще, помимо изменения базы данных через модель объекта. А модель сущностей просто служит для того, чтобы поддерживать простоту отношений с базой данных, позволяя мне «проходить» данные по всем внешним ссылкам в базе данных.

Я бы не стал редактировать сгенерированные файлы, так как они могут измениться.

Что вы можете сделать, так это обернуть их неким объектом запроса и передать его.

ayende делает очень хорошее замечание о том, где DAL действительно должен жить

Кроме того, вы должны быть поклонником viewmodels/dtos;)

Я предпочитаю оборачивать вызовы классов сущностей в бизнес-классы. (Для краткости назовем его BC.) Каждый BC имеет несколько конструкторов, один или несколько из которых позволяют передавать ему контекст. Это позволяет одному BC вызывать другой BC и загружать связанные данные в том же контексте. Это также упрощает работу с коллекциями BC, которым нужен общий контекст.

В конструкторах, которые не принимают контекст, я создаю новый контекст в самом конструкторе. Я делаю контекст доступным через свойство только для чтения, к которому могут получить доступ другие BC.

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

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