2012-03-17 12 views
5

He estado tratando de encontrar lo diferente entre MVC y la arquitectura de 3 niveles en ASP.NET. Me referí a algunas preguntas anteriores y algunas páginas anteriores, pero podría encontrar una respuesta clara.
Aquí es AA página de MSDN acerca de la implementación MVC: http://msdn.microsoft.com/en-us/library/ff647462.aspxDiferencia entre el controlador MVC y la lógica de negocios (3 niveles)

tener en cuenta, me tienen este código:
sola página aspx interfaz de usuario y el código, así

<%@ Import Namespace="System.Data" %> 
<%@ Import Namespace="System.Data.SqlClient" %> 
<html> 
    <head> 
     <title>start</title> 
     <script language="c#" runat="server"> 
     void Page_Load(object sender, System.EventArgs e) 
     { 
      String selectCmd = "select * from Recording"; 

      SqlConnection myConnection = 
       new SqlConnection(
        "server=(local);database=recordings;Trusted_Connection=yes"); 
      SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, 
       myConnection); 

      DataSet ds = new DataSet(); 
      myCommand.Fill(ds, "Recording"); 

      recordingSelect.DataSource = ds; 
      recordingSelect.DataTextField = "title"; 
      recordingSelect.DataValueField = "id"; 
      recordingSelect.DataBind(); 
     } 
     </script> 
    </head> 
    <body> 
     <asp:dropdownlist id="recordingSelect" runat="server" /> 
     <asp:button runat="server" text="Submit" OnClick="SubmitBtn_Click" /> 
     </form> 
    </body> 
</html> 

Ahora, tenga en cuenta que tengo diferentes archivos para
---- View y de código subyacente spearated ----
.aspx

<%@ Page language="c#" Codebehind="Solution.aspx.cs" 
    AutoEventWireup="false" Inherits="Solution" %> 
<html> 
     <asp:dropdownlist id="recordingSelect" runat="server" /> 
     </form> 
    </body> 
</html> 

.aspx.cs

using System; 
using System.Data; 
using System.Data.SqlClient; 
public class Solution : System.Web.UI.Page 
{ 
    private void Page_Load(object sender, System.EventArgs e) 
    { 
     if(!IsPostBack) 
     { 
     String selectCmd = "select * from Recording"; 
     SqlConnection myConnection = 
      new SqlConnection(
       "server=(local);database=recordings;Trusted_Connection=yes"); 
     SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection); 
     DataSet ds = new DataSet(); 
     myCommand.Fill(ds, "Recording"); 
     recordingSelect.DataSource = ds; 
     recordingSelect.DataTextField = "title"; 
     recordingSelect.DataValueField = "id"; 
     recordingSelect.DataBind(); 
     } 
    } 
  1. Al ver lo anterior msdn page link para la clase Controller, no soy capaz de discernir la diferencia entre la lógica de negocio (que habría sido similar para un nivel medio en una arquitectura de 3 niveles) y el controlador.
  2. ¿Es 3 niveles y MVC algo completamente diferente? ¿La aplicación ASP.NET en Visual Studio ya está separada del archivo como en el formulario MVC? Si no son diferentes, ¿cuál es el estilo preferido?
  3. ¿De qué se trata el framework MVC si los archivos .aspx y .aspx.cs ya están escritos?

Respuesta

5

En realidad strugled con este un tiempo myslef, hay diferentes filosofías sobre cómo implementar correctamente, así que esto es como yo lo entiendo en mis propias palabras cómo me entender la relación entre las diferentes cosas que participan (Modelos/Vistas/Controladores/lógica de negocios):

  • Vistas
    tienen todas el código HTML/jQuery, que utilizan los datos en forma de Model casos que vienen desde el controlador
  • Modelos
    las clases que contienen la información de su vista necesita render (Lista de productos etc)
  • Controladores
    • Toman las peticiones entrantes
    • hacer los preparativos necesarios (extracción de parámetros, etc.) para llamar a su código de lógica empresarial real.
    • entonces la llamada en el código de lógica de negocio y recuperar el resultado
    • Después se toma el resultado y lo transforma en un modelo que la interfaz de usuario entiende
  • La lógica de negocio
    Este es el código de la lógica de negocio real , llamando al db etc. Considero que esto está totalmente separado de todo lo de MVC, de hecho ni siquiera debería saber que se ejecuta desde una aplicación web de MVC. Por lo general, ponemos esto en un ensamblaje diferente (biblioteca de clases) para asegurarnos de que no haya ninguna dependencia del código MVC.
    Esto hace que sea muy simple probar la unidad simplemente con la lógica de negocios, ya que no hay dependencias con MVC.

He visto otros enfoques donde la lógica de negocios se pone realmente en los controladores, pero a mis ojos eso frustra el propósito. No estamos creando aplicaciones MVC para tener una estructura agradable, sino también para poder realizar mejor la prueba unitaria.

Volviendo a su pregunta, ¿cómo se relaciona todo con la arquitectura ASP.NET de 3 niveles.
Se podría decir que, básicamente, toda la aplicación web MVC no es más que la capa de presentación (+ el cableado de la capa de presentación con la capa de Busines).

Las otras capas permanecen separadas e independientes de la capa de presentación, como deberían haberlo hecho anteriormente.

+0

. Esto es completamente cierto. También diría que las Vistas contienen la lógica de presentación mientras que los Controladores contienen la lógica de la aplicación en el nivel de presentación. Además, el Modelo es generalmente parte de la capa de negocios. –

+0

@BalazsTihanyi En realidad llegamos al extremo de no hacer que la capa empresarial conozca los modelos utilizados por las vistas, la capa empresarial usa un conjunto diferente de 'modelos' y los resultados se asignan a los modelos dentro de los controladores (automapper i ' m mirándote) – ntziolis

0

Ver here para una buena comparación entre las "capas" y "niveles" en la arquitectura de software/diseño

El patrón MVC es todo acerca de la separación de intereses, y el hecho de que su capa de presentación (la vista) y la lógica de negocios debería estar separada. Usar el código detrás hace que sea fácil enturbiar las aguas. Descubrirá que el nuevo motor de visualización ASP.NET (Razor) ni siquiera tiene código detrás de los archivos.

La principal diferencia, que comenzará a importar más cuando se quiere probar la lógica en su controlador automáticamente, es que un controlador es simplemente una vieja clase simple, pero su código hereda de System.Web.UI.Page y por lo tanto, está fuertemente ligado a las entrañas de ASP.net.

Además, lea http://ardalis.com/Codebehind-Files-in-ASP.NET-MVC-are-Evil y https://msmvps.com/blogs/luisabreu/archive/2008/09/19/codebehind-files-in-asp-net-mvc-are-not-evil.aspx

+0

Lo leí antes. Me parece que la única diferencia es que las M & V pueden interactuar directamente con Controller (en MVC), que por otro lado en una arquitectura de 3 niveles, la comunicación debe hacerse a través de la lógica comercial. Parece dos enfoques diferentes, con una diferencia perceptible fina. ¿Hay una ventaja de elegir entre MVC o 3 niveles? – user1240679

+0

Diría que 3 niveles y MVC son conceptos muy diferentes (como el patrón MVC se usa ahora), 3 niveles se refiere más a tener su acceso de datos lógicamente (y a menudo físicamente) separado de su lógica comercial, por lo que en los términos actuales MVC se convierte los primeros dos niveles de su aplicación, pero todavía tiene un "nivel" de acceso a datos detrás de ese – Rich

+0

Esta pregunta también aborda MVC vs 3 niveles http://stackoverflow.com/questions/1025430/i-need-some-clarification -on-the-mvc-architecture-and-the-three-tier-architectur – Rich

2

MVC y 3 niveles son completamente diferentes cosas.
Veo mucha gente confundir a los dos porque ambos tienen 3 partes.

MVC es un patrón IU:
Ver: contiene HTML y JS solamente (en el caso de un proyecto web)
controlador: es una especie de mediador entre la interfaz de usuario (= la vista) y el back-end (= modelo)
modelo: Aquí es donde viven sus objetos de dominio, así como la lógica de negocio y de acceso a datos

de 3 niveles concierne a toda de que aplicación:
IU: contiene el código HTML/JS, así como el código detrás de las páginas.
Hay absolutamente sin lógica aquí, que no sea el código de UI y llamando a la capa empresarial.
Business layer: aquí es donde se ponen cosas como cálculos, condiciones, validación, ..
Entonces, el comportamiento real de su aplicación. No hay código de acceso a datos aquí.
Acceso a datos: aquí donde habla con la base de datos y devuelve los datos a la capa empresarial.
Nada más, la capa empresarial debe saber qué hacer con ella.

Así que si combinan los dos, obtendrá:
de interfaz de usuario: vistas y controladores
negocios capas: una parte del modelo
acceso de datos: parte del modelo de objetos
Dominio: que' Quiero poner los objetos con los que está trabajando (producto, orden, ...) en una capa separada.
Esto también forma parte del modelo.

Dispara si tienes preguntas!

Cuestiones relacionadas