依赖注入VS单，动初始化

我工作的一个大项目，现在，应用程序正在采取的许多不同的服务优势，因为：评论，喜欢，帖子，购买等..

我有一个类为每个服务。

现在，我来到了一个地步，我想限制注册用户而已，对于一些行动，帖子，评论，等等..

截至目前每类使用只具有类的方法，如下所示：

@interface UpdateOrderServies : NSObject 

+(void)deleteOrder: (STOrder *)order 
     andReturn: (void(^)(NSError *error))errorBlock; 

+(void)updateOrder: (STOrder *)order 
     andReturn: (void(^)(NSError *error))errorBlock;

但是现在，我想首先检查用户是否注册，如果不是，则不返回值。所以我figgerd是最好的出路是改变类SINGEL基调，并要求每一个类被调用时，如果用户registerd像这样：

+(id) getInstance { 

    static UpdateOrderServies *__sharedDataModel = nil; 
    static dispatch_once_t onceToken; 
    dispatch_once(&onceToken, ^{ 
     __sharedDataModel = [[UpdateOrderServies alloc]init]; 

    }); 

    if (![__sharedDataModel userIsRegisterd]) { 
     return nil; 
    } 

    return __sharedDataModel; 

}

和它的作品，但是，好了，它不是一个非常好的答案，你可以看到..我想要更通用的东西。我正在考虑使用台风依赖注入，但没有地方我可以检查每个电话，如果用户注册... 任何想法更好的方式来处理这个问题？更多动态...

感谢

来源

2014-07-16 MCMatan

为什么不在用户首次“登录”或以其他方式标识自己时，用一个封装了所有授权的“能力”对象等等来使用它，而不是使用简单的用户标识来标识用户，以及查询该对象以测试用户的能力。 –

@HotLicks“为什么不在用户登录时识别用户”。。该步骤是身份验证。接下来是定义调用给定服务所需的权限 - 这部分称为授权。我们可以将授权作为每个服务调用的一部分，但这会破坏单一责任原则 - 因此推荐使用AOP。 –

@JasperBlues - 将“责任”放在用户的能力对象中。必须呈现该能力才能执行授权操作。这对我来说似乎是一个“单一责任”计划。 –

此基础上你的问题，我觉得你不是在找依赖注入，但面向方面编程。（Aspect Orientes Programming，AOP）旨在准确解决上述问题 - 这些问题贯穿系统中的许多模块。示例：

每次用户与服务进行交互，应检查安全性。
所有交易应该有一个审计跟踪
每家商店interraction应导致Genius推荐

如果我们使用这些跨领域的要求正常的面向对象编程中，我们打破单一职责原则和一个应该几乎涉及一个主题的类现在扮演着更多的角色，这会让人感到困惑，重复和混乱。

AOP将这些横切关注点模块化，然后使用方法拦截确定应该应用这些横切关注点的所有位置。（在AOP中，我们称之为点切表达式）。

在Objective-c中，您可以使用ISA-swizzling，消息转发或使用NSProxy来执行手动AOP--这些都是在运行时实现方法拦截的方法。或者，您可以使用Pete Steinberger和团队的图书馆和一个名为'Aspects'的图书馆。这个库目前还没有一个切点表达式语言，但仍然比使用ObjC运行时直接拦截方法简单得多。

的授权方面将如何工作总结：

在登录时进行身份验证，我们我们的用户，使用用户名/密码挑战，OAuth令牌或相似。验证用户后，我们现在可以授权服务调用。
确定需要授权的每项服务以及所需的权限（您可以使用角色，功能等任何方案）。
良好的面向对象的原则说，每个班级应该有一个单一的责任。所以你的服务客户端应该都是关于调用远程服务的。我们可以编辑服务客户端来评估登录用户的权限并决定是否继续。但是这将是混乱和重复的。相反，我们将在步骤2中使用这些信息（每项服务需要许可），并将该评估委托给我们的授权模块。
现在AOP步骤：对于每个服务调用，我们都会告诉我们的AOP库拦截服务客户端方法并首先调用授权模块。

这样你的交叉要求（授权客户端调用）不会重复。现在您可以为了简单起见，决定让每个服务调用调用授权模块，但它仍然有助于了解AOP背后的理论和横切关注点。

依赖注入/台风

依赖注入并没有真正直接关系到你的问题，但它肯定能帮助我们避免你的单身客户的陷阱：

创建一个明确的合同在你的类之间 - 增加代码的凝聚力。
确定应用程序中的关键'actors'，并描述它们被组装成整体的方式。可以将一名演员换成另一名演员来完成同样的合同。
简化使用模拟和存根的单元测试。
简化集成测试 - 可以将一个参与者替换为另一个参与者，以使系统进入所需状态。例如，只修补一个授权模块。

来源

2014-07-17 00:42:04

依赖注入VS单，动初始化

回答

相关问题