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

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

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

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

  1. Открытый идентификатор/открытая авторизация

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

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

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

Ваш бизнес-уровень должен быть своего рода plug and play в любом приложении.

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

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

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

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


c# asp.net-mvc asp.net-mvc-3 service-layer
person chobo2    schedule 24.01.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

person John Farrell    schedule 24.01.2011