Ух ты, Камьяр, всего несколько вопросов, завернутых в этом вопросе ;-) Я не уверен, что рассмотрю все возможные варианты, но здесь все в порядке.
ProjectStructure
- как правило, ваша структура проектов правильная, а ваши рекомендации верны. Некоторые могут возразить, что вы хотите немного отделить свои проблемы и разбить некоторые ссылки, но лично я считаю вашу структуру работоспособной.
На практике я склоняюсь к тому, чтобы мои EDXM и POCO оставались в одном проекте. У меня просто есть папка Entities, в которой находятся EDXM и Model.Context.tt, папка POCO для Model.tt и моего Virtual POCO (ниже), а также папка Repository для моего хранилища и единицы работы.
Я также создаю файл с именем VirtualPOCOs, который является частичным классом, связанным с POCO, генерируемыми вашими T4. Мои проекты обычно тесно связаны со структурой базы данных. VirtualPOCO дает мне небольшую гибкость, чтобы отклоняться от дизайна БД в этих одноразовых ситуациях. Здесь не так уж много, просто те несколько очень специфических потребностей, которые, похоже, есть у каждого проекта.
Возможно, вы также захотите рассмотреть хранилище, шлюз табличных данных или настройку активной записи. Все эти модели, скорее всего, будут объединены с Единицей Работы. Существует множество шаблонов дизайна, и ваши потребности или предпочтения могут подтолкнуть вас к тому или иному. Суть в том, чтобы защитить верхние уровни от прямого доступа к контексту EF4. Таким образом, вы можете централизовать управление соединениями и транзакциями и убедиться, что верхние уровни используют только POCO и не случайно держатся за объекты linq-to-sql.
Поставщик членства
Определенно существует раскол между MembershipProvider и EF. Однако вы можете загрузить исходный код для SQLMembershipProvider и преобразовать его для использования EF. Я на самом деле сделал это преобразование. Файл имеет длину около 1500 строк, но не содержит большого количества кода ADO.
То, что вы не спрашивали, но я думаю, что мне следует обратиться, это то, хотите ли вы вообще использовать поставщика членства. Если вы занимаетесь базовым управлением членством и ролями, то поставщик членства, ролей и профилей может сэкономить вам много времени. Для подробного ознакомления с возможностями посмотрите серию на 4GuysFromRolla (http://www.4guysfromrolla.com/articles/120705-1.aspx).
Если ваши потребности более сложны, то, имхо, поставщик членства довольно быстро выходит из строя. Например, когда пользователь регистрируется на вашем сайте, вам сразу нужно создать строки в нескольких разных таблицах. Ну, поставщик членства зарегистрирован через webconfig и использует интерфейс поставщика членства. Он принимает только определенные поля в функции создания. Так что же делать мальчику? Итак, вы можете открыть более крупную транзакцию на вашем контроллере, запустить поставщиков членства, добавить функцию пользователя, запустить собственную MyCustomUserStuff(), а затем зафиксировать транзакцию. Две причины, по которым я нахожу это непривлекательным, заключаются в том, что теперь мой транзакционный код просачивается вверх по моему стеку вызовов, и если все, что мне нужно сделать, это добавить несколько дополнительных полей, то теперь я теперь без необходимости удваиваю свои вызовы базы данных.
Полагаю, я просто посчитал, что поставщик членства довольно ограничен, и однажды попал туда и сделал своего собственного провайдера членства, преимущества использования модели MS быстро отпали.
проверка
Я думаю, что ответ здесь звучит громко - это зависит. Ваши разрешения довольно статичны? то есть те, кто в группе "SiteManagers" могут редактировать весь сайт? Или ваши разрешения гораздо более детализированы? То есть у SiteManager есть доступ к этим 75 полям, разбросанным по этим 22 таблицам, или это больше основано на таблицах? Кроме того, насколько изменчивы разрешения? Нужно ли администратору вашего сайта часто включать / выключать доступ к различным полям в разных таблицах?
Я думаю, что мне нужно услышать больше о ваших требованиях для конкретного ответа.Имейте в виду, что чем более детально вы настроили ваши разрешения, тем больше головной боли при настройке клиент получит для понимания и управления всеми разрешениями.
Кроме того, какой бэкэнд вы используете?Многие DBA сталкиваются с этими решениями.Одна из часто используемых стратегий в этом мире - создать серию представлений, где каждое представление отображает столбцы, которые есть у пользователей.Например, в представлении EmployeesHR будут отображаться только те столбцы, к которым имеют доступ сотрудники отдела кадров, а в EmployeeDirectory будут отображаться только те поля, к которым имеет доступ каталог. Затем пользователям HR предоставляется разрешение на представление HR, но небазовая таблица.Просто мысль.
В любом случае, надеюсь, это поможет.