Платформа объекта ПОСТЕПЕННО Объекты во много веб-приложении слоя
Я плохо знаком с EF4 и не имел никакого опыта с ним прежде. Так, терпите меня, если это - очень простой вопрос. У меня есть мой ПОСТЕПЕННО объекты (.tt файл) в BOL, .edmx файл (EDM) в DAL и мое веб-приложение на Уровне представления. Вся бизнес-логика переходит к уровню BLL. Вот ссылки:
UI-> BLL-DAL-BOL
BLL-> DAL-BOL
DAL-> BOL
BOL-> Ни один из моего проекта.
1-мое понимание корректного различия слоев? Я нахожусь в правильном направлении? 2-, Как я могу использовать поставщика Членства ASP.NET с объектами. Я должен реализовать членство, персистентность, неосведомленная также, и отобразить все пользовательские таблицы в SQL-сервере к объектам?
2-, Как я могу добавить пользовательскую проверку? Я не имею в виду maxlength или действующий адрес электронной почты..., я имею в виду что-то как уровни доступа. Например, я хочу определенных пользователей смочь изменить поле (скажите что productprice) в моем веб-сайте. Где я должен использовать Пользователя. Метод IsInRole? BLL не имеет никакой ссылки на информацию о пользователе, я должен передать некоторые параметры BLL (как "bool CanChangePrice") для разъяснения уровней доступа?
3 ответа
Ух ты, Камьяр, в этом только несколько вопросов ;-) Я не уверен, что отвечу на все возможные земля, но здесь идет.
ProjectStructure
- в целом ваша структура проектов верна, и ссылки, которые у вас есть, верны. Некоторые могут возразить, что вы хотите немного разделить свои опасения и нарушить некоторые ссылки, но лично я считаю вашу структуру работоспособной.
С практической точки зрения я стараюсь держать свои EDXM и POCO в одном проекте. У меня просто есть папка Entities, содержащая EDXM и Model.Context.tt, папка POCO для Model.tt и моих виртуальных POCO (ниже) и папка репозитория для моего репозитория и единицы работы.
Я также создаю файл VirtualPOCOs, который является частичным классом, привязанным к POCO, созданным вашим T4. Мои проекты, как правило, довольно сильно привязаны к структуре базы данных. VirtualPOCO дает мне некоторую гибкость, чтобы отклониться от дизайна БД в этих разовых ситуациях. Здесь не так уж много, просто те несколько очень специфических потребностей, которые, похоже, есть у каждого проекта.
Вы также можете рассмотреть возможность настройки репозитория, шлюза табличных данных или активной записи. Все эти шаблоны, скорее всего, будут объединены с Unit of Work. Существует множество шаблонов проектирования, и ваши потребности или предпочтения могут подтолкнуть вас к тому или иному. Дело здесь в том, чтобы защитить верхние уровни от прямого доступа к контексту EF4. Таким образом, вы можете централизовать управление подключениями и транзакциями и гарантировать, что верхние уровни используют только POCO и случайно не держатся за объекты linq-to-sql.
Поставщик членства
Определенно существует раскол между MembershipProvider и EF. Однако вы можете загрузить исходный код для SQLMembershipProvider и преобразовать его для использования EF. Я действительно сделал это преобразование. Длина файла составляет около 1500 строк, но он не содержит большого количества кода ADO.
То, что вы не спрашивали, но я думаю, что я должен ответить, это то, хотите ли вы вообще использовать поставщика членства. Если вы выполняете базовое управление членством и ролями, то поставщик членства, ролей и профиля может сэкономить вам много времени. Для более подробного ознакомления с возможностями ознакомьтесь с серией игр на 4GuysFromRolla ( http://www.4guysfromrolla.com/articles/120705-1.aspx ).
Если ваши потребности более сложные, то, ИМХО, поставщик членства быстро выходит из строя. Например, когда пользователь регистрируется на вашем сайте, вам немедленно нужно создать строки в нескольких различных таблицах. Что ж, провайдер членства регистрируется через webconfig и использует интерфейс провайдера членства. Он принимает только определенные поля в функции создания. Так что же делать мальчику? Что ж, вы можете открыть крупномасштабную транзакцию в своем контроллере, запустить поставщиков членства, добавить функцию пользователя, запустить свой собственный MyCustomUserStuff () , а затем зафиксировать транзакцию. Я считаю это непривлекательным по двум причинам: теперь у меня есть транзакционный код, просачивающийся вверх по стеку вызовов, и если все, что мне нужно сделать, это добавить несколько дополнительных полей, я без нужды удвоил количество обращений к базе данных.
Думаю, я просто нашел поставщика членства довольно ограничивающим, и как только я вошел в него и сделал моего собственного поставщика членства, преимущества использования модели MS быстро отпали.
Подтверждение
Я думаю, что ответ здесь однозначный - это зависит от обстоятельств. Ваши разрешения довольно статичны? т.е. те, кто находится в группе "Менеджеры сайта", могут редактировать на всем сайте? Или ваши разрешения намного более детализированы? Это означает, что у SiteManager есть доступ к этим 75 полям, распределенным по этим 22 таблицам, или это больше основано на таблицах? Кроме того, насколько изменчивы разрешения? Должен ли администратор вашего сайта иметь возможность часто включать / отключать доступ к различным полям в разных таблицах?
Думаю, мне нужно услышать больше о ваших требованиях для конкретного ответа. Имейте в виду, что чем более детально вы сделаете свои разрешения, тем больше проблем с конфигурацией будет у клиента, понимая и управляя всеми разрешениями.
Кроме того, какую серверную часть вы используете? Многие администраторы баз данных сталкиваются с этими решениями. Одна из часто используемых стратегий в этом мире - создать серию представлений, в каждой из которых представлены столбцы, которые есть у пользователей. Например, представление EmployeesHR будет отображать только те столбцы, к которым имеют доступ сотрудники отдела кадров, а EmployeeDirectory будет отображать только те поля, к которым каталог имеет доступ. Затем будут предоставлены пользователи HR. разрешение на просмотр HR, но не для базовой таблицы. Просто мысль.
В любом случае, надеюсь, это поможет.
1- Мне кажется, что вы правильно различаете слои. Я бы не стал ссылаться на DAL в пользовательском интерфейсе, так как в моих проектах я предпочитаю, чтобы только средний уровень имел доступ к DAL. Но это не так. Итак, вы, кажется, в правильном направлении.
2- Насколько мне известно, не существует MembershipProvider, работающего с EF.
Итак, в проектах, где мы использовали членство, вот что мы сделали:
- создали таблицы с
aspnet_regsql.exe - настроили
Web.Configдля использованияSqlMembershiptProvider - добавлен в web.config ДРУГАЯ строка подключения (одна для членства и одна для EF)
- Создал файл EDMX со всеми таблицами, включая таблицы членства.
В коде UserManager / RoleManager (BLL или DAL, в зависимости от вашей архитектуры) получает информацию, используя стандартные методы членства. И всегда используйте объекты членства, а не EF. Фактически, часть управления пользователями / ролями отделена от EF.
Мы используем объекты EF aspnet _ * только тогда, когда есть связь между вашими настраиваемыми таблицами и таблицей членства (например, когда вы хотите связать одну из своих таблиц с aspnet_Users , чтобы сохранить ссылку на пользователя, вставившего данные).
3- Для правильного управления я бы использовал BLL RightManager , который позволил бы пользовательскому интерфейсу узнать, может ли пользователь изменить поле (чтобы вы могли отключить его или запретить ввод), и чтобы используйте эту информацию в своем методе проверки.
В своем проекте я использую таблицу Right и связываю Right с ролью.В RightManager предоставляется метод RequestRight (Right) .
Если ваше управление правами слишком просто для создания таблиц, просто используйте User.IsInRole () в вашем RightManager (так что я бы использовал его в BLL).
Я бы поместил метод проверки в пользовательский интерфейс, если он «базовый», и в BLL, если он содержит более сложные правила (например, включая доступ к DAL).
об EF и членстве как я знаю, вам не нужно использовать какого-либо поставщика db вместо поставщика членства но при желании вы можете сопоставить таблицы членства в EF и создать дополнительный метод для общий провайдер