Diseño (arquitectura) del proyecto .NET Entity Framework

Question

Estoy tratando de determinar cuál es 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 navegación donde los jugadores poseen y operan planetas.Así es como lo tengo:

Sitio web

Este contiene todo el front-end.

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

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

Desde el sitio web, haré algo como esto:

var planet = PlanetManager.getPlanet(1);

Devuelve un Planeta objeto de MLS.Game.Data (generado a partir de EDMX).Funciona, pero me molesta hasta cierto punto porque significa que mi interfaz tiene que hacer referencia a MLS.Game.Data.Sin embargo, siempre he sentido que la GUI solo debería hacer referencia al proyecto empresarial.

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

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

EDITAR

Sin embargo, después de un poco más, hay elementos adicionales que me molestan.Por ejemplo, digamos que tengo mi objeto Planet, que nuevamente es código generado por el asistente.¿Qué pasaría si llegara el momento en que mi Planeta necesitara tener una propiedad especializada, digamos "Población", que es un cálculo de algún tipo basado en otras propiedades del objeto Planeta?¿Me gustarí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

Usted podría intentar lo siguiente para mejorar las cosas:

• Use EF para ir a buscar dtos en su capa de datos, a continuación, utilizar estos dtos para poblar los objetos de negocio más ricos en su capa de negocio. sólo entonces podría necesitar su interfaz de usuario para hacer referencia a la capa de negocio.
• Una vez que haya creado los ricos objetos de negocio, puede comenzar a internalizar parte de la lógica de las clases de dirigentes, la limpieza efectiva de la capa de negocio.

Yo personalmente prefiero el modelo más rica sobre el modelo de director porque, como dice usted, usted termina con una carga de métodos estáticos, que se termina por encadenar inevitibly dentro de otros métodos estáticos. Esto me parece a la vez demasiado desordenada y, más importante, más difícil de entender y garantizar la consistencia de los objetos en cualquier punto dado en el tiempo.

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

Una buena pregunta por el camino.

Answer 2

En mi humilde opinión, la presentación actual está muy bien. Es perfectamente normal que su interfaz de usuario para hacer referencia a la capa de 'datos' como la que está llamando él. Creo que tal vez su preocupación frente debido a la terminología. El 'Datos' que usted ha descrito más a menudo se refiere como capa de unos objetos de negocio '' (BOL). Un diseño común sería entonces tener una capa de lógica de negocio (BLL), que es la capa de 'Managers' y una capa de acceso a datos (DAL). En su escenario, LINQ a ENTIDADES (suponiendo que usará ese) es su DAL. Un patrón de referencia normal sería entonces: -

interfaz de usuario hace referencia a BLL y BOL. BLL refences BOL y DAL (LINQ a ENTIDADES).

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

Answer 3

En cuanto a su segunda pregunta (después de la edición) si necesita o desea agregar características a su EF objetos que se pueden utilizar las clases parciales. Haga clic derecho en el archivo y seleccione EDMX código de la vista.

O si esto no es suficiente para que usted puede deshacerse de la diseñadora y escribir sus propias clases habilitadas EF.

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

Answer 4

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

Si no me equivoco, las clases generadas por EF no están sellados, y son PARCIAL clases, por lo que fácilmente se podría extender a los mismos 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 sus propios "PlanetAddons.cs" (o como se quiera llamarlo) para extender esta clase:

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

Con buena pinta, ¿verdad? No hay necesidad de derivar y crear jerarquías de objetos artificiales ....

Marc

Answer 5

No soy un experto, pero que suena bastante bien para mí. Eso similar a lo que tengo en mis soluciones, excepto que acabo de fusionar el proyecto de EF con el proyecto empresarial. Mis soluciones no son tan grandes, y mis objetos no requieren una gran cantidad de inteligencia, por lo que está bien para mí. Yo también tengo un montón de diferentes métodos para cada una de mis clases de ayuda estáticas.

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

Answer 6

Su diseño se ve bien. Me hubiera añadido una capa de Utilidad / Común

interfaz de usuario web
Capa de negocio
DataObjects
Utilidades capa

Answer 7

Yo añadiría dtos a la capa de negocio que son representaciones de objetos "mudo" (es decir, sólo propiedades) de las entidades en la capa de datos. A continuación, sus clases "manager" ellos pueden regresar, como por ejemplo:

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

y la interfaz de usuario sólo puede hacer frente a la capa BLL a través POCOs; El director (lo que yo llamaría una clase "Mapper") se encarga de 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 tienen el Administrador de traducir ese nuevo a sus componentes.