Хотелось бы при каждом вызове методов бизнес-компонента выполнять некие действия прозрачно для самого бизнес-компонента. Неправильно сформулировал насчет аудита, вообщем Security.
Здравствуйте, PeterZT, Вы писали:
PZT>Хотелось бы при каждом вызове методов бизнес-компонента выполнять некие действия прозрачно для самого бизнес-компонента. Неправильно сформулировал насчет аудита, вообщем Security.
Через AOP, EnterpriseServices
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Через АОП (ContextBoundObject) как-то не очень понятно. В MSDN пишут "The ContextAttribute type supports the .NET Framework infrastructure and is not intended to be used directly from your code", и все в таком духе. Возникает вопрос не перестанет ли это работать в поздних версиях .NET Framework.
Смысл вообще такой. Планируется n-tier система. У пользователей имеется загрузчик с авторизатором, пользователи регистрируются на сервере, получают свой набор сборок и работают периодически обращаясь к бизнес-логике через Remoting. Планируется создать прозрачную для самого приложения(кроме загрузчика и сервис-компонентов на сервере) систему Role-Based Security. EnterpriseServices не хотелось бы использовать из-за возможных проблем с деплойментом и оверхида COM interop.
PZT>Смысл вообще такой. Планируется n-tier система. У пользователей имеется загрузчик с авторизатором, пользователи регистрируются на сервере, получают свой набор сборок и работают периодически обращаясь к бизнес-логике через Remoting. Планируется создать прозрачную для самого приложения(кроме загрузчика и сервис-компонентов на сервере) систему Role-Based Security. EnterpriseServices не хотелось бы использовать из-за возможных проблем с деплойментом и оверхида COM interop.
Я такую систему разработал на СОМе
она отлично работает с СОМ объектами и соответственно
с .НЕТ объектами запущенными под СОМ+ и соотв. отнаследованными EnterpriseServices.
на .нет тоже не вижу принципиальных трудностей перехватить вызов(если не собираешься все запускать под СОМ+)
смотри в сторону транспарент/реал прокси и тп
в сторону механизма маршалинга и ремутинга в .нете.
ЕД>смотри в сторону транспарент/реал прокси и тп ЕД>в сторону механизма маршалинга и ремутинга в .нете.
Хотелось бы чтобы обработка происходила на server-side, поэтому real-proxy не подойдет, соответственно мне нужно вставить свой сервер-синк в канал, я правильно понимаю ?
Здравствуйте, PeterZT, Вы писали:
PZT>Через АОП (ContextBoundObject) как-то не очень понятно. В MSDN пишут "The ContextAttribute type supports the .NET Framework infrastructure and is not intended to be used directly from your code", и все в таком духе. Возникает вопрос не перестанет ли это работать в поздних версиях .NET Framework. PZT>Смысл вообще такой. Планируется n-tier система. У пользователей имеется загрузчик с авторизатором, пользователи регистрируются на сервере, получают свой набор сборок и работают периодически обращаясь к бизнес-логике через Remoting. Планируется создать прозрачную для самого приложения(кроме загрузчика и сервис-компонентов на сервере) систему Role-Based Security. EnterpriseServices не хотелось бы использовать из-за возможных проблем с деплойментом и оверхида COM interop.
Извини, что не писал. для role-based security никакой AOP не нужен. погляди Role-based security здесь. Проблема в том, что, если система сложная, то тебе придется наворачивать кучу всего с группами пользователей, вложенными группами и, отдельную базенку с хранением ролей и т.д.. Поскольку COM+ role based security пользуется Windows группами, то, может, лучше пользоваться им? Это, конечно, при условии, что все пользователи есть в Active Directory.
PS Я не пользовался COM+ role based security, так что, лучше поговорить с теми, кто пользовался. Я храню пользователей в отдельной БД, но у меня сейчас приложение не очень большое нужно и планируются пользователи извне. В дальнейшем планирую сам перейти, т.к. мне (издалека ) кажется, что это должно быть удобнее.
) кажется, что это должно быть удобнее.
