2

私はこのような構造を持っています

WebUIプロジェクト-コントローラー、ビューフレームワークプロジェクト-リポジトリ、サービスレイヤーおよびドメイン

だから今私は3つのメソッド/クラスを持っています

  1. Open Id / Open auth

最初は、すべてのロジックをフレームワークプロジェクトのサービスレイヤーに配置すると思いました（リクエストの準備、応答の確認などはこのレイヤーにあります）。

だから今私はdotnetopenauthライブラリを使用していて、コントローラーでAsActionResultメソッドを使用する必要があるためです（サービスレイヤーにMVCが必要ないため、サービスレイヤーから "OutgoingWebResponse"を返します）

サービスレイヤーにMVCを何も持たないことにしたとき、私は考えさせられました。私が読んだように、ビジネスロジックを含むサービスレイヤーにはMVC参照のような依存関係があってはなりません。これは、Windows Phoneアプリケーションにアクセスする場合、MVCのものを使用するべきではないためです。

ビジネスレイヤーは、あらゆるアプリケーションへのプラグアンドプレイのようなものでなければなりません。

したがって、上記の理由だけで、openId用に作成したものをmvcプロジェクトのmodelsフォルダーに移動する必要があるかどうかがわかりません。Windows Phoneアプリケーションまたはフォームアプリケーションにアクセスした場合、これらのタイプのアプリケーションではサポートされていないと思われるため、dotnetopenauthを使用しません。

  1. 2つ目は、フォーム認証です。繰り返しますが、上記とほぼ同じ理由です。これは、ローカルサービス/リポジトリレイヤー（つまり、同じプロジェクトファイル内）と同じようにモデルフォルダーに配置する必要があります。

  2. 私はnhibernate、fluent nhiberate、ninjectを使用しています。私のリポジトリはすべて私のフレームワークプロジェクトにあります。だから私はもちろんそこにすべての参照を持っています。しかし、私はiocにninjectを使用しているので、webuiプロジェクトにもすべての参照があります。

私のwebuiからこれらの参照を取り除くためにこれを変更できるかどうかはわかりません。彼らは私が行くべきだと思う私のwebuiに私のiocを置くことができないので、私はノーと考えています。

4

1 に答える 1

0

一般的な経験則として、存在しない要件（アプリをWindows Phoneに移植する）に対してコードを記述しないでください。

通常、これをサービスレイヤーで抽象化しますが、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 に答える