2

我有这样的结构

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

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

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

起初我以为我会将所有逻辑放在我的框架项目中的服务层中（准备请求，检查响应等将在该层中）。

所以现在我正在使用 dotnetopenauth 库，因为我需要在我的控制器中使用 AsActionResult 方法（我从我的服务层返回“OutgoingWebResponse”，因为我不希望我的服务层中有任何 MVC）

当我决定在我的服务层中不包含任何 MVC 时，我开始思考。正如我所读到的，包含业务逻辑的服务层不应具有任何依赖项，例如 MVC 引用，因为如果您使用 Windows Phone 应用程序，则不应使用 MVC 的东西。

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

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

  1. 我的第二个是表单身份验证。再次与上述几乎相同的原因。这是否应该在我的模型文件夹中作为本地服务/repo 层（即在同一个项目文件中）。

  2. 我正在使用 nhibernate、流利的 nhiberate 和 ninject。我的回购都在我的框架项目中。所以我当然有所有的参考资料。但由于我使用 ninject 进行 ioc，所以我的 webui 项目中也有所有引用。

我不知道是否可以更改这个以从我的 webui 中删除这些引用。我在想不，因为他们我的 ioc 不能放在我认为应该去的 webui 中。

4

1 回答 1

0

作为一般经验法则，您不应该针对不存在的需求编写代码（将应用程序移植到 Windows 手机）。

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

由于“所有抽象都是泄漏的”，您将遇到的问题是，无论您将服务层放置在何处，openauth 注册过程都会以某种方式破坏您的服务层。有关用户注册和登录的详细信息（例如他们的 openid url 是什么）最终会出现在您的数据库中。您的 service/repo/db/model/mvc/viewmodel/controllers 类都将知道 openauth 是什么，因为它的性质。

好消息是这些基于浏览器的身份验证策略可以存在于 Windows 窗体、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 之外的另一个平台。

于 2011-01-24T04:53:30.060 回答