c# - proyectos - proyecto base anexsoft

Diseño de proyecto de marco de entidad de.NET(arquitectura)

Question

Estoy tratando de determinar la mejor manera de diseñar un proyecto .NET Entity Framework para lograr un buen enfoque en capas. Hasta ahora lo he probado en un juego basado en navegar donde los jugadores poseen y operan planetas. Así es como lo tengo:

Sitio web

Esto contiene todo el frente.

Proyecto C # - MLS.Game.Data

Este contiene el archivo EDMX con todas mis asignaciones de datos. No hay mucho más aquí.

Proyecto C # - MLS.Game.Business

Esto contiene varias clases que llamo ''Administradores'' como PlanetManager.cs. El administrador del planeta tiene varios métodos estáticos que se usan para interactuar con el planeta, como getPlanet (int planetID) que devolvería un objeto de código generado de MLS.Game.Data.

Desde el sitio web, haré algo como esto:

var planet = PlanetManager.getPlanet(1);

Devuelve un objeto Planet desde MLS.Game.Data (generado desde el EDMX). Funciona, pero me molesta hasta cierto punto porque significa que mi parte delantera tiene que hacer referencia a MLS.Game.Data. Siempre he pensado que la GUI solo debería hacer referencia al proyecto Business.

Además, he descubierto que mis clases de Gerente tienden a ser muy pesadas. Terminaré con docenas de métodos estáticos en ellos.

Entonces ... mi pregunta es: ¿cómo los demás diseñan sus proyectos ASP EF?

EDITAR

Sin embargo, después de algunos más, hay elementos adicionales que me molestan. Por ejemplo, digamos que tengo mi objeto Planet, que de nuevo es código generado por el asistente. ¿Qué pasa si llega el momento en que mi planeta necesita tener una propiedad especializada, decir "Población" que es un tipo de cálculo basado en otras propiedades del objeto Planeta. ¿Querría crear una nueva clase que herede de Planet y luego devolverla? (hmm, me pregunto si esas clases están selladas por el EF?)

Gracias

Answer 1

No soy un experto, pero eso suena bastante bien para mí. Eso es similar a lo que tengo en mis soluciones, excepto que simplemente fusiono el proyecto EF con el proyecto empresarial. Mis soluciones no son tan grandes, y mis objetos no requieren mucha inteligencia, así que está bien para mí. También tengo una tonelada de métodos diferentes para cada una de mis clases estáticas de ayuda.

Si no desea que la capa de presentación conozca la capa de acceso a los datos, entonces debe crear algunas clases intermedias, lo que probablemente sería mucho trabajo. Entonces, ¿cuál es el problema con su configuración actual?

Answer 2

Puede intentar lo siguiente para mejorar las cosas:

• Use EF para buscar DTO en su capa de Datos, luego use estos DTO para poblar objetos comerciales más ricos en su capa de Negocios. Su UI solo necesitaría hacer referencia a la capa Business.
• Una vez que haya creado los objetos de negocio enriquecidos, puede comenzar a internalizar parte de la lógica de las clases de administrador, limpiando eficazmente la capa de negocio.

Yo personalmente prefiero el modelo más rico que el modelo de administrador porque, como dices, terminas con una carga de métodos estáticos, que inevitablemente terminas encadenando dentro de otros métodos estáticos. Encuentro esto demasiado complicado y, lo que es más importante, más difícil de entender y garantizar la coherencia de tus objetos en un momento dado.

Si encapsula la lógica dentro de la clase, puede estar más seguro del estado de su objeto, independientemente de la naturaleza de la persona que llama.

Una buena pregunta por cierto.

Answer 3

Tu diseño se ve bien Yo habría agregado una capa de Utilidad / Común

UI web
Capa empresarial
Objetos de datos
Capa de utilidades

Answer 4

En mi humilde opinión, su diseño actual está bien. Es perfectamente normal que su UI haga referencia a la capa ''Datos'' cuando la está llamando. Creo que tal vez su preocupación surja debido a la terminología. Los ''Datos'' que ha descrito se refieren con mayor frecuencia a la capa ''objetos comerciales'' (BOL). Un diseño común sería tener una capa de lógica de negocios (BLL) que es su capa de ''Gerentes'' y una capa de acceso a datos (DAL). En su escenario, LINQ to Entites (suponiendo que usará eso) es su DAL. Un patrón de referencia normal sería entonces:

UI hace referencia a BLL y BOL. BLL refiera BOL y DAL (LINQ a Entites).

Eche un vistazo a esta serie de artículos para obtener más detalles.

Answer 5

Agregaría DTO a su capa de negocios que son representaciones de "objetos tontos" (es decir, solo propiedades) de las entidades en su capa de datos. Luego, las clases de "Gerente" pueden devolverlas, como por ejemplo:

class PlanetManager
{
    public static PlanetDTO GetPlanet(int id) { // ... }
}

y su UI solo puede tratar con la capa BLL a través de POCO; el Administrador (lo que yo llamaría una clase "Mapeador") maneja toda la traducción entre los objetos y la capa de datos. Además, si necesita extender la clase, puede tener una propiedad "virtual" en el objeto DTO y hacer que Manager la traduzca a sus componentes.

Answer 6

En cuanto a su segunda pregunta (después del EDIT) si necesita o desea agregar funciones a sus objetos EF, puede usar clases parciales. Haga clic derecho en el archivo EDMX y seleccione ver código.

O, si esto no es suficiente, puede deshacerse del diseñador y escribir sus propias clases EF habilitadas.

Hay una discusión (breve) de ambas opciones aquí: http://msdn.microsoft.com/en-us/library/bb738612.aspx

Answer 7

En cuanto a su segunda pregunta en la sección "EDITAR":

Si no me equivoco, las clases generadas por EF no están selladas, y son clases PARCIAL , por lo que podría extenderlas sin tocar los archivos generados.

La clase generada será:

public partial class Planet : global::System.Data.Objects.DataClasses.EntityObject
{
 ...
}

para que pueda crear fácilmente su propio "PlanetAddons.cs" (o lo que sea que quiera llamarlo) para extender esta clase:

public partial class Planet 
{
 property int Population {get; set;} 
 ...
}

Bastante limpio, ¿eh? No es necesario derivar y crear jerarquías de objetos artificiales ....

Bagazo