Сущности Entity Framework POCO в многослойном веб-приложении
Я новичок в EF4 и не имел никакого опыта с ним раньше. Итак, потерпите, если это очень простой вопрос. У меня есть мои сущности POCO (.TT file) в бол .файл edmx (EDM) в DAL и мой webapp в слое презентации. Вся бизнес-логика идет на уровень BLL. Вот ссылки:
UI->BLL-DAL-BOL
BLL->ДАЛЬ-БОЛ
даль->бол
бол - >ни один из моих проектов.
1 - мой понимание различий слоев правильное? Я в правильном направлении? 2-Как я могу использовать ASP.NET поставщик членства с сущностями. Должен ли я реализовать членство, сохраняемость и сопоставление всех пользовательских таблиц в sql server с сущностями?
2-Как добавить пользовательскую проверку? Я не имею в виду maxlength или действительную электронную почту... Я имею в виду что-то вроде уровни доступа. Например, я хочу, чтобы некоторые пользователи могли изменять поле (скажем, productprice) на моем веб-сайте. Где мне быть? используйте пользователя.Метод IsInRole? BLL не имеет никакой ссылки на информацию о пользователе. должен ли я передать некоторые параметры BLL (например, "bool CanChangePrice") для уточнения уровней доступа?
3 ответов
Вау Камьяр, всего несколько вопросов, завернутых в этом; -) я не уверен, что я буду охватывать все возможные земли, но здесь идет.
ProjectStructure
- как правило, ваша структура проектов правильная, и ссылки у вас есть правильные. Кто-то может возразить, что вы хотите немного отделить свои проблемы и сломать некоторые ссылки, но лично я считаю вашу структуру работоспособной.
как практический вопрос я склонен чтобы сохранить EDXM и POCOs в одном проекте. У меня просто есть папка Entities, содержащая EDXM и модель.Контекст.tt, папка POCO для модели.tt и мои виртуальные POCO (ниже), а также папка репозитория для моего репозитория и единицы работы.
Я также создаю файл под названием VirtualPOCOs, который является частичным классом, привязанным к POCOs, генерируемым вашими T4. Мои проекты, как правило, довольно тесно связаны со структурой базы данных. VirtualPOCO дают мне немного гибкости отклониться от дизайна БД в этих одноразовых ситуациях. Здесь не так много, просто те несколько очень конкретных потребностей, которые, похоже, есть у каждого проекта.
вы также можете рассмотреть возможность установки хранилища, табличного шлюза данных или активной записи. Все эти модели, скорее всего, будут объединены с единицей работы. Есть тонны шаблонов дизайна, и ваши потребности или предпочтения могут подтолкнуть вас к тому или другому. Дело в том, чтобы защитить верхние слои от доступа к В ef4 контексте напрямую. Таким образом, вы можете централизовать управление соединениями и транзакциями и гарантировать, что верхние слои используют только POCOs и случайно не удерживают объекты linq-to-sql.
Поставщика
Существует определенный раскол между MembershipProvider и EF. Однако вы можете загрузить исходный код для SQLMembershipProvider и преобразовать его в EF. Я действительно сделал это преобразование. Файла составляет около 1500 строки длинные, но не имеют большого количества кода ADO.
то, что вы не спросили, но я думаю, что я должен обратиться, является ли вы хотите использовать поставщика членства вообще. Если вы занимаетесь базовым управлением членством и ролями, то членство, роли и поставщик профилей могут сэкономить вам много времени. Для углубленного тура возможностей проверьте серию на 4guysfromrolla (http://www.4guysfromrolla.com/articles/120705-1.aspx).
Если ваши потребности более сложны, ИМХО, поставщик членства ломается довольно быстро. Например, когда пользователь регистрируется для вашего сайта, Вам сразу же нужно создать строки в нескольких разных таблицах. Ну, поставщик членства зарегистрирован через webconfig и использует интерфейс поставщика членства. Он принимает только определенные поля в функции create. Так что же делать мальчику? Ну, вы можете открыть крупномасштабную транзакцию в своем контроллере, запустить членство поставщики добавить функцию пользователя, запустить свой собственный MyCustomUserStuff(), после совершения сделки. Две причины, по которым я нахожу это непривлекательным, в том, что у меня теперь есть транзакционный код, просачивающийся в мой стек вызовов, и если все, что мне нужно сделать, это добавить несколько дополнительных полей, я теперь удвоил свои вызовы базы данных без необходимости.
Я думаю, что я просто нашел поставщика членства довольно ограничивающим, и однажды попал туда и сделал свой собственный поставщик членства преимущества использования модели MS быстро отпали.
проверка
Я думаю, что ответ здесь однозначный-в зависимости от. Ваши разрешения довольно статичны? т. е. в "SiteManagers" группы может редактировать во всем сайте? Или ваши разрешения гораздо более мелкозернистые? Значение SiteManagers имеет доступ к этим 75 полям, разбросанным по этим 22 таблицам, или это больше на основе таблиц? Кроме того, насколько изменчивы разрешения ? Должен ли ваш администратор сайта иметь возможность часто включать/выключать доступ или в разные поля в разных таблицах?
Я думаю, что мне нужно услышать больше о ваших требованиях для конкретного ответа. Имейте в виду, что чем более мелкозернистыми вы делаете свои разрешения, тем больше головной боли конфигурации клиент будет иметь понимание и управление всеми разрешениями.
кроме того, какой бэк-энд вы используете? Многие DBA сталкиваются с этими решениями. Одной из часто используемых стратегий в этом мире является создание ряда представлений, в которых каждое представление предоставляет столбцы пользователи. Например,EmployeesHR view выставит только те столбцы, к которым люди HR имеют доступ, и EmployeeDirectory будет предоставлять только те поля, к которым имеет доступ каталог.Затем пользователи HR получают разрешение на представление HR, но не на базовую таблицу. Просто мысль.
В любом случае, надеюсь, это поможет.
1 - ваше различие слоев кажется мне правильным. Я бы не ссылался на DAL в пользовательском интерфейсе, как в моих проектах, я предпочитаю, чтобы только средний уровень имел доступ к DAL. Но это не так. Так что вы, кажется, в правильном направлении.
2 - Насколько мне известно, нет MembershipProvider, который работает с EF.
Поэтому в проектах, где мы использовали членство, вот что мы сделали :
- создал таблицы с
aspnet_regsql.exe - настройки
Web.ConfigиспользоватьSqlMembershiptProvider - добавил в web.настройте другую строку подключения (одну для членства и одну для EF)
- построил файл EDMX со всеми таблицами, включая таблицы членства.
в коде a UserManager / RoleManager (BLL или DAL это зависит от вашей архитектуры) получить информацию, используя стандартные методы членства. И всегда используйте объекты членства, а не EF. Таким образом, фактически часть управления пользователями / ролями отделена от эмиттерный повторитель.
мы используем только aspnet_* сущности EF, когда есть связь между пользовательскими таблицами и таблицей членства (например, когда вы хотите связать одну из своих таблиц с aspnet_Users таблица для хранения ссылки пользователя, вставившего данные).
3 - для правильного управления я бы использовал BLL RightManager это позволит пользовательскому интерфейсу узнать, может ли пользователь изменить поле (чтобы вы могли отключить его или запретить ввод), и использовать эту информацию в своей проверке метод.
В моем проекте я использую Right таблица и я связываем право с ролью. В RightManager обеспечить RequestRight(Right) метод.
Если ваше правильное управление слишком просто для создания таблиц, просто используйте User.IsInRole () в вашем RightManager (поэтому я бы использовал его в BLL).
Я бы разместил метод проверки в пользовательском интерфейсе, если он" базовый", и в BLL, если он содержит более сложные правила (например, с доступом DAL).
о EF & членстве как я знаю, вам не нужно использовать какого-либо поставщика БД вместо поставщика членства но если вы хотите, вы можете сопоставить таблицы членства в ЕР и создать дополнительный метод общий поставщик