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

Question

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

Это означает, что «пользователь» бизнес-объектов (контроллер, сервис-слой, ...) должен знать о объекте datacontext, который необходим для использования linq.

Это также означает, что DAL-логика и бизнес-логика будут смешаны.

Во многих примерах Microsoft используется некий DTO-подход. Я не большой поклонник модели DTO.

Итак, я должен позволить бизнес-объекту инкапсулировать linq-сущность и предоставить доступ к ней с помощью свойств, или мне следует придерживаться шаблона DTO?

Каковы ваши предложения?

Спасибо

Answer 1

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

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

---

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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