Вопрос трехуровневой архитектуры

Question

У меня есть приложение ASP.NET с трехуровневой архитектурой:

• Уровень представления: ASP.NET

• Бизнес слой: C# библиотека.

• Уровень доступа к данным: библиотека C# с
  Объекты ADO.Net Entity Framework.

Некоторые методы на уровне Bussiness возвращают объекты сущностей ADO.NET, но уровень доступа к данным не виден на уровне презентации. Я не могу этого сделать.

У меня вопрос: В представлении конструктора правильно ли выставлять объектные объекты на уровне представления? Я думаю, что мне нужно только связать библиотеку Data Layer с приложением ASP.NET.

Спасибо!

Answer 1

Я предлагаю вам взглянуть на концепции объектов View... или Data Transfer Objects (DTO). Вы можете рассмотреть возможность использования инструмента, такого как AutoMapper или аналогичного, который создаст видовой объект предметной области из ваших сущностей. Как правило, у вас могут быть экраны, для которых требуется наличие объекта для выполнения своей работы. Но чаще всего вам нужно будет пройти несколько разных объектов. В этом случае вам лучше создать один DTO, содержащий все эти объекты. Делая это, вы добавляете слой разделения между уровнем представления и уровнем бизнеса. Часто ваши сущности имеют больше возможностей, чем вы могли бы представить на уровне представления. И наоборот. Часто вам может потребоваться отправить некоторые сообщения пользовательского интерфейса на уровень представления на основе проверки, отмеченной на вашем бизнес-уровне. Вместо того чтобы сделать ваш пользовательский интерфейс более сложным, чем нужно (передавая полные сущности), вы можете передать только то, что нужно пользовательскому интерфейсу, в форме DTO. Кроме того, вашим бизнес-объектам никогда не нужно заботиться о чем-либо специфичном для уровня представления. Я предлагаю, чтобы вы не связывали данные напрямую с уровнем доступа к данным. Технически ваш уровень представления должен знать как можно меньше о вашем уровне бизнеса. В случае MVP или MVC этого очень легко достичь, отсоединив передний конец и задний конец с помощью этого дополнительного разделения!

Answer 2

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

• Привязка коллекции объектов к сетке / списку / выпадающему списку
• Выделение одного объекта (например, клиента) на форму для чтения / обновления / удаления

Это делает вашу жизнь намного проще. В противном случае вам придется передавать строку после int после двойной за строкой между вашей презентацией и бизнес-уровнями.

Это могут быть объекты Entity или даже ваши собственные объекты POCO, которые были гидратированы из объектов Entity.

Я бы даже сказал, что ваши Entites должны быть в своей собственной сборке отдельно от DAL.

Answer 3

Я думаю, что нет, лучший способ сделать это - отделить классы данных от поведения и ссылаться только на классы данных на уровне представления. Думаю, хороший подход к использованию WCF приведен по этой ссылке.

Answer 4

См. Контролирующий контроллер и пассивный вид

Если вы передаете сущность, вы по сути контролирующий контролер. В противном случае вы пассивный вид.

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

Обычно я придерживаюсь Supervising Controller. Обычно вам не нужен такой уровень тестируемости, и это не стоит дополнительных хлопот.