¿A dónde deben ir estas clases/métodos?

Question

Tengo una estructura como esta

Proyecto WebUI - Controladores, Proyecto Marco Vistas - Repositorios, capa de servicio y dominio

Así que ahora tengo 3 métodos/clases

1. Auth ID/Autor abierto

Al principio pensé que pondría toda mi lógica en una capa de servicio en mi proyecto de marco (preparar la solicitud, verificar la respuesta, etc. estaría en esta capa).

Así que ahora estoy usando la biblioteca DotnetoPenauth y porque necesito usar el método AsactionResult en mi controlador (devuelvo "OuturingWebResponse" de mi capa de servicio, ya que no quiero nada MVC en mis capas de servicio)

Me hizo pensar cuando decidí no tener nada MVC en mi capa de servicio. Como leí es que su capa de servicio que contiene la lógica de su negocio no debe tener dependencias como referencias de MVC porque si va a una aplicación de Windows Phone, no debe usar cosas de MVC.

Su capa comercial debe ser un tipo de enchufe y jugar en cualquier aplicación.

Así que ahora no estoy seguro de si debería mover lo que escribí para OpenID en mi carpeta de modelos en mi proyecto MVC, por las razones anteriores. Dado que si voy a una aplicación de Windows Phone o una aplicación Forms, no usaré DotnetOpenauth, ya que no creo que sea compatible con este tipo de aplicaciones.

1. Mi segundo es con la autenticación de formularios. De nuevo, más o menos las mismas razones que anteriores. Si esto va tan bien en la carpeta de mi modelos como una capa de servicio/repo local (es decir, en el mismo archivo de proyecto).

2. Estoy usando nhibernado, fluido nhiberado y ninguno. Mis reposuras están todos en mi proyecto de marco. Así que, por supuesto, tengo todas las referencias allí. Pero como estoy usando Ninject para IOC, también tengo todas las referencias en mi proyecto webui.

No tengo idea de si este podría cambiarse para deshacerse de estas referencias de mi webui. Estoy pensando que no porque no puedo tener mi COI en mi webui donde creo que debería ir.

Answer 1

Como regla general, no debe escribir código contra los requisitos que no existen (portando la aplicación a un teléfono con Windows).

Normalmente abstrae esto en su capa de servicio, sin embargo, la integración OAuth o Facebook plantea un problema debido a su dependencia de HTTP y poder visitar el sitio de autenticación.

El problema con el que te encontrarás porque "Todas las abstracciones son con fugas"Es que el proceso de registro de OpenAuth se dañará de alguna manera su capa de servicio. /Model/MVC/ViewModel/Controllers Las clases sabrán qué se debe a OpenAuth por su naturaleza.

Lo bueno es que estas estrategias de autenticación basadas en el navegador pueden vivir en forma de Windows, WPF o Silverlight. Simplemente abra un navegador dentro de la aplicación en lugar de redirigir de forma nativa con MVC.

Entonces, lo que recomendaría es colocar su código de registro de Auth DotnetoPen dentro de su capa de servicio y en realidad abstraer cómo ocurre el proceso de redirección y devolución de llamada.

Algo como:

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 );
    }   

}

Ahora los diferentes detalles de implementación son flexibles y puede hacer una transición fácilmente a otra plataforma además de MVC.