我有这样的结构

WebUI项目 - 控制器,视图框架项目 - 存储库,服务层和域

所以现在我有 3 个方法/类

  1. 开放ID/开放身份验证

起初我以为我会将所有逻辑放在框架项目的服务层中(准备请求、检查响应等都在这一层中)。

所以现在我正在使用 dotnetopenauth 库,因为我需要在控制器中使用 AsActionResult 方法(我从服务层返回“OutgoingWebResponse”,因为我不想在服务层中使用任何 MVC)

当我决定不在我的服务层中使用任何 MVC 时,这让我开始思考。据我所知,包含业务逻辑的服务层不应具有任何依赖项(例如 MVC 引用),因为如果您使用 Windows Phone 应用程序,则不应使用 MVC 内容。

您的业​​务层应该可以在任何应用程序中即插即用。

所以现在我不确定是否应该将我为 openId 编写的内容移动到我的 mvc 项目中的 models 文件夹中,只是出于上述原因。因为如果我确实使用 Windows Phone 应用程序或表单应用程序,我将不会使用 dotnetopenauth,因为我认为这些类型的应用程序不支持它。

  1. 我的第二个是表单身份验证。同样的原因与上面几乎相同。这应该在我的模型文件夹中作为本地服务/存储库层(即在同一个项目文件中)。

  2. 我正在使用 nhibernate、Fluent nhiberate 和 ninject。我的仓库都在我的框架项目中。所以我当然有所有的参考资料。但由于我使用 ninject 进行 ioc,所以我的 webui 项目中也有所有参考资料。

我不知道是否可以更改此内容以从我的 webui 中删除这些引用。我想不,因为他们我不能把我的ioc放在我认为它应该去的地方。

有帮助吗?

解决方案

作为一般经验法则,您不应根据不存在的要求编写代码(将应用程序移植到 Windows Phone)。

通常,您会在服务层中将其抽象出来,但是 OAuth 或 Facebook 集成会带来问题,因为它依赖于 http 并且能够访问身份验证站点。

你会遇到的问题是因为“所有抽象都有漏洞” 的问题是,无论您将其放置在何处,您的服务层都会因 openauth 注册过程而以某种方式损坏。有关用户注册和登录的详细信息(例如他们的 openid url 是什么)最终将存储在您的数据库中。由于 openauth 的本质,您的 service/repo/db/model/mvc/viewmodel/controllers 类都会知道 openauth 是什么。

好处是这些基于浏览器的身份验证策略可以存在于 Windows Form、WPF 或 Silverlight 应用程序中。您只需在应用程序内打开浏览器,而不是使用 MVC 进行本机重定向。

因此,我建议将 dotnetopen 身份验证注册代码放置在服务层内,并实际抽象出重定向和回调过程如何发生。

就像是:

public interface IOpenAuthRedirect
{
      public void Redirect( url )
      public void ParseCallback( url )
}


public class MVCOpenAuthRedirect
{
     public void Redirect(url)
     {
        HttpContext.Current.Response.Redirect(url);
     }
}

public class SilverlightOpenAuthRedirect
{
    public void RedirectUrl( url )
    {
        SomeBrowserControl.IForgetTheCallToRedirect( url );
    }   

}

现在,不同的实现细节很灵活,您可以轻松过渡到 MVC 之外的另一个平台。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top