Estructurando una solución de C # de winforms

Question

Por lo tanto, estoy reorganizando una solución C # de winforms para ayudar a desacoplarla y hacerla más limpia y organizada. La solución rastrea los pedidos de una pequeña empresa, etc. .

He desglosado los proyectos hasta ahora

App.View : todos los códigos relacionados con GUI
Datos de aplicación : solo estructuras de datos e interfaces. Ningún otro código de implementación
App.BusinessLogic : todo el código de lógica de negocios que no tiene referencias GUI

Tengo algunas clases que no puedo averiguar a dónde pertenecen. Déjeme saber sus pensamientos sobre qué proyecto debe ir cada clase o si hay otro proyecto que debe crearse para esto.

1. Una clase que recupera las preferencias del usuario de una base de datos
2. Una clase que recupera datos estáticos de nuestro servidor de datos estáticos y devuelve conjuntos de resultados de datos.
3. Una clase que reduce los derechos de los usuarios
4. Una clase modelo que almacena una tabla hash de pedidos
5. Una clase que envía mensajes de correo electrónico sobre una acción de usuario

Answer 1

En realidad, creo que tienes cosas un poco alejadas de una arquitectura en capas tradicional. Normalmente, los modelos de sus datos en los que trabaja su aplicación se mantendrían en una capa empresarial, junto con el código para operar en ellos. Su capa de datos tendría los modelos de datos de su marco de persistencia y el código para interactuar con ese marco. Creo que esto podría ser la fuente de la confusión entre las ubicaciones sugeridas de tus clases y tu reacción a esto en base a tus comentarios.

Desde esa perspectiva, cualquier cosa que se recupere o aporte se ubicará necesariamente en su capa de datos: está accediendo a los datos en un almacenamiento persistente. Lo que recupera se convierte eventualmente en objetos de la capa de negocios en los que opera su lógica de negocios. Las cosas son modelos conceptuales, como una tabla de pedidos, o acciones comerciales que pertenecen a la capa empresarial. Estoy de acuerdo con @Adron con, tal vez, con la misma confusión sobre a dónde va (3) dependiendo de lo que realmente sea.

Más específicamente:

1. Las preferencias de usuario son negocios Objetos, lo que recupera. ellos es un objeto de capa de datos.
2. Los datos estáticos se asignan a una empresa objeto (tabla o vista o algo), Lo que accede a lo externo. El servidor es un objeto de capa de datos.
3. El derecho del usuario es un objeto de negocio, lo que lo recupera es el objeto de capa de datos.
4. Una tabla de pedidos es un objeto de negocio
5. El envío de correos electrónicos es una actividad comercial, por lo que lo que se envía a las personas es un objeto comercial

[EDITAR] Mi arquitectura generalizada de 3 niveles para aplicaciones web (simples)

DataAccessLayer

Esto incluiría mis TableAdapters y DataTables y Factories fuertemente tipados que convierten las filas de mis DataTables en objetos de negocios en proyectos pre-LINQ. Al usar LINQ, esto incluiría las entidades LINQ generadas por DataContext y el diseñador.

BusinessLayer

Esto incluiría cualquier lógica de negocios, incluida la validación y la seguridad. En pre-LINQ, estos serían mis objetos comerciales y cualquier otra clase que implemente la lógica de la aplicación. Usando LINQ, estas son las implementaciones parciales de clase de mis entidades LINQ para implementar la seguridad y la validación junto con cualquier otra clase para implementar la lógica empresarial.

Presentación

Estos son mis formularios web, básicamente la interfaz de usuario de la aplicación. Incluyo parte de la lógica de validación en las formas como una optimización, aunque éstas también se validan en el BL. Esto también incluiría cualquier control de usuario.

Nota: Esta es la estructura lógica. La estructura del proyecto generalmente refleja esto, pero hay algunos casos, como las conexiones a servicios web, que pueden incluirse directamente en el proyecto web, aunque lógicamente los componentes están realmente en el BL / DAL.

Nota: probablemente me mudaré a MVC a más de 3 niveles una vez que ASP.NET MVC esté en producción. He realizado algunos proyectos personales en Ruby / Rails y me gusta mucho el paradigma MVC para aplicaciones web.

Answer 2

Ha especificado que App.Data debe contener solo estructuras de datos e interfaces, no código de implementación, lo cual está bien si quiere hacer eso, pero eso no le deja a nadie lugar para colocar su código de acceso a la base de datos, excepto en su App.BusinessLogic montaje.

Tal vez realmente necesite cambiar el nombre de App.Data a App.Model (o algo similar), y tener un nuevo conjunto App.DataAccess que se comunique con la base de datos (tal vez implementando un patrón de Repository). Habiendo hecho eso, dividiría las cosas así:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

Probablemente iría con

1. datos
2. datos
3. Datos, aunque no estoy completamente seguro de lo que hace la clase
4. datos
5. BusinessLogic

Answer 4

1. - > App.Data
2. - > App.Data
3. - > App.BusinessLogic o App.Data: no estoy seguro de qué significa exactamente.
4. - > App.BusinessLogic
5. - > App.BusinessLogic