Вот кое-что, что вы можете рассмотреть.
Я бы использовал шаблон декоратора для отдельной авторизации каждого вызова вашего объекта.
Допустим, у вас есть следующий класс:
public class MyService
{
public virtual void DoSomething()
{
//do something on the server
}
}
Затем вы приступите к созданию базового декоратора для реализации конструктора по умолчанию, например:
public class MyServiceDecoratorBase : MyService
{
public MyServiceDecoratorBase(MyService service)
{
}
}
После настройки вы можете начать оформление, создав авторизационный декоратор, подобный следующему:
public class MyServiceAuthorizationDecorator : MyServiceDecoratorBase
{
private readonly MyService _service;
public MyServiceDecoratorBase(MyService service)
{
_service = service;
}
public override void DoSomething()
{
//TODO: Authorize the user here.
_service.DoSomething();
}
}
Так что теперь, когда основные классы сделаны ... как вы собираетесь все это называть? Легко!
MyService service = new MyServiceAuthorizationDecorator(new MyService());
service.DoSomething();
Теперь ... преимущество всего в том, что ваша логика авторизации полностью отделена от логики вашего основного сервиса (или объекта). Почему это важно? Тестируемость. Вы можете протестировать свой основной сервис независимо от логики авторизации. Это соответствует принципу открытия / закрытия.
Теперь, допустим, вы хотите рассчитать производительность для этих надоедливых методов ... добавьте декоратор! Логирование? Еще один декоратор! Все они могут быть прикованы таким образом. Конечно, чем больше вы добавляете и тем тяжелее это становится, но я думаю, что оно того стоит за преимущество, которое оно дает.
Комментарии