Скрытие классов Entity Model от уровня представления - PullRequest
1 голос
/ 14 июля 2011

Я занимаюсь разработкой приложения для веб-форм на C # Framework 3.5

Я хочу создать что-то вроде потока «Presentation> BLL> DAL> Entity Model» в моем приложении. Но проблема в том, что, как я буду использовать объекты объектов в слое презентации?

Предложения

Ответы [ 3 ]

2 голосов
/ 14 июля 2011

Используете ли вы Entity Framework?

Если это так, используйте генератор POCO вместо объекта EntityObject по умолчанию.

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

Я бы предложил перенести POCO (и связанный шаблон T4, который создает генератор POCO) в другой проект, на который ссылаются Presentation Layer, BLL и DAL.

EDIT:

Альтернатива (если генератор POCO не работает в 3.5) - вручную создавать классы домена и использовать их в интерфейсе с DAL. Это увеличивает усилия, но я рекомендую НЕ выставлять объекты EntityObject за пределами DAL.

1 голос
/ 14 июля 2011

На самом деле я бы выбрал следующий подход:

Имейте модели (POCO), например, в проекте, на который ссылаются только ваши DAL и BLL. Это позволит вам работать с ними на уровне DAL и применять к ним бизнес-логику в BLL.

Для уровня представления я бы создал DTO (объекты передачи данных), которые будут переносить только те данные, которые вам нужны для определенного сценария / объекта. Перевод между DTO и POCO я бы поместил в BLL.

Я могу подумать о следующих плюсах и минусах этого подхода:

1) Плюсы

- Полное разделение между уровнями представления и ядра (BLL, DAL). Ваши DTO будут независимы от базы данных (POCO), что означает, что независимо от того, какие изменения вы вносите в базу данных, вам нужно будет изменить это только на уровне переводов.

- стабильный BLL API - Разделение проверки - вы можете выполнить проверку на DTO для презентации и на POCO для BLL.

2) Минусы

- Правила перевода для каждого POCO-to-DTO. Это неизбежно усложнит ваш код, но я считаю, что это хорошая отдача. - Производительность накладных расходов. Перевод и создание экземпляров DTO и POCO добавят некоторые накладные расходы к вашему приложению. В зависимости от ваших требований и возможностей машины вы можете решить, является ли это хорошей окупаемостью.

Я также советую вам взглянуть на некоторые библиотеки отображений, которые позволяют легко отображать / переводить между различными типами объектов. На мой взгляд, лучшим является ThisMember как по простоте, так и по производительности.

Привет

0 голосов
/ 14 июля 2011

Я бы предложил вам поместить EDM в слой данных. Тогда есть еще один общий проект, имеющий все классы сущностей Poco. Вы можете использовать Protocol Buffer for .net для сопоставления этих объектов сущности с вашими объектами poco.

В bll вы можете создавать классы адаптеров, и это должно быть единственным интерфейсом между презентацией и dal. Bll должен связываться с уровнем представления, используя сущности poco.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...