Архитектура ASP.Net MVC 3 с EF - PullRequest
Новая
       44

Архитектура ASP.Net MVC 3 с EF

2 голосов
/ 03 ноября 2011

Я пытаюсь спроектировать свой веб-проект MVC, и у меня возникла небольшая проблема.

Я использую EF4.1. Я создал проект DataAccess с файлом EDMX. Затем я использую генератор dbContext для создания своих классов POCO .tt.

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

Мне кажется, что я должен создать еще один уровень абстракции и поместить файлы dbContext .tt в их собственный проект, чтобы и уровень BusinessLogic, и уровень презентации могли получить доступ к классам POCO, но только BusinessLogic имеет доступ к структура сущности. Уровень представления не должен знать ничего об EF.

Как то так ... 

POCO Classes - DataAccess
    |             |
    |---------Business Logic
    |             |
    |_________Presentation

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

Ответы [ 3 ]

2 голосов
/ 03 ноября 2011

Ваш уровень представления не должен ничего знать об EF.Просто обратитесь к этому проекту из уровня презентации, чтобы получить доступ к моделям.

Однако - уровень презентации не должен в идеале использовать любую из этих моделей POCO.Они должны использовать ViewModels.Я не обязательно верю в DTO здесь, поскольку DTO имеют конкретную цель.Ваш репозиторий / доступ к данным может возвращать модели, но обычно они возвращаются на уровень обслуживания.Служебный уровень затем возвращает ваше представление ViewModel вашему контроллеру.

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

По иронии судьбы, я думаю, что в скором времени я буду работать над книгой по этой конкретной теме:)

0 голосов
/ 03 ноября 2011

Итак, есть несколько способов структурировать ваш проект.То, на что вы ссылаетесь, это один из способов, которым вы делитесь poco между всеми слоями.

Другой способ состоит в том, чтобы ваши POCO находились на уровне данных и бизнеса, а затем создавали аналогичную объектную модель, которая используется совместно с пользовательским интерфейсом и бизнес-уровнем.Наконец, вы можете также создать третью модель для пользовательского интерфейса, которая называется ViewModel.

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

0 голосов
/ 03 ноября 2011

Рассмотрите возможность отправки объектов передачи данных между уровнями бизнес-логики и презентации. Это позволит вам формировать данные для ваших представлений и предотвращать утечку информации на уровень презентации (например, если у вас есть поле в POCO, которое необходимо для вашей бизнес-логики, но не должно быть доступно на уровне презентации) ).

Вопрос в том, как бы вы перемещали данные в и из слой представления? Другими словами, если слой презентации держать ссылку на сборку модели домена? (В Entity Framework В этом случае сборка модели домена - это просто DLL, созданная из Файл EDMX.)

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

Уровень DTO изолирует модель предметной области от представления, что приводит как к слабой связи, так и к оптимизированной передаче данных.

Если вы идете по этому маршруту, также проверьте Automapper , чтобы помочь с отображением ваших DTO в POCO и наоборот.

...