Куда должны идти эти классы / методы? - PullRequest
Новая
       7

Куда должны идти эти классы / методы?

2 голосов
/ 24 января 2011

У меня есть такая структура

Проект WebUI - контроллеры, представления Framework, репозитории проекта, сервисный уровень и домен

Так что теперь у меня есть 3 метода / класса

  1. Open Id / Open auth

Сначала я подумал, что я бы поместил всю свою логику в сервисный уровень в моем проекте фреймворка (подготовка запроса, проверка ответа и т. Д. Были бы на этом уровне).

Так что теперь я использую библиотеку dotnetopenauth, и потому что мне нужно использовать метод AsActionResult в моем контроллере (я возвращаю «OutgoingWebResponse» из моего сервисного уровня, так как я не хочу ничего MVC в моих сервисных слоях)

Это заставило меня задуматься, когда я решил не иметь ничего MVC на своем уровне обслуживания.Как я прочитал, у вашего сервисного уровня, который содержит вашу бизнес-логику, не должно быть никаких зависимостей, таких как ссылки MVC, потому что если вы переходите в приложение Windows Phone, вам не следует использовать MVC.

Ваш бизнес-уровень должен бытьсвоего рода подключи и играй в любое приложение.

Так что теперь я не уверен, стоит ли мне перемещать то, что я написал для openId, в папку с моими моделями в моем проекте MVC просто по вышеуказанным причинам.Поскольку, если я перейду к приложению Windows Phone или приложению форм, я не буду использовать dotnetopenauth, так как не думаю, что он поддерживается в приложениях такого типа.

  1. Мой второй вариантс аутентификацией форм.Опять же по тем же причинам, что и выше.Должно ли это пойти в папке с моими моделями в качестве локального слоя обслуживания / репо (то есть в том же файле проекта).

  2. Я использую nhibernate, беглый nhiberate и ninject.Все мои репозитории находятся в моем каркасном проекте.Так что у меня есть, конечно, все ссылки там.Но так как я использую ninject для ioc, у меня есть все ссылки в моем проекте webui.

Я понятия не имею, можно ли изменить эту ссылку, чтобы избавиться от этих ссылок из моегоWebUI.Я думаю нет, потому что они не могут иметь свой ioc в моем webui, где я думаю, что он должен идти.

1 Ответ

0 голосов
/ 24 января 2011

Как общее практическое правило, вы не должны писать код в соответствии с несуществующими требованиями (портирование приложения на Windows Phone).

Обычно вы бы абстрагировали это на своем уровне обслуживания, однако интеграция OAuth или Facebook создает проблему из-за ее зависимости от http и возможности посещать сайт аутентификации.

Проблема, с которой вы столкнетесь, потому что " все абстракции имеют утечку " заключается в том, что ваш уровень обслуживания будет каким-то образом поврежден процессом регистрации openauth независимо от того, где вы его разместите. Подробная информация о регистрации пользователя и логине, например, его openid URL, попадет в вашу базу данных. Вы - классы 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.

...