propiedad tag c#

Estructurar una solución Cforms de winforms

Question

Así que estoy reorganizando una solución Cforms de winforms para ayudar a desacoplarla y hacerla más limpia y organizada. La solución rastrea pedidos de pequeñas empresas, etc. .

He roto los proyectos hasta ahora en

App.View : todo el código relacionado con la GUI
App.Data : solo estructuras de datos e interfaces. Ningún otro código de implementación
App.BusinessLogic : código de lógica empresarial que no tiene referencias de GUI

Tengo algunas clases que no puedo entender a dónde pertenecen. Por favor, hágame saber sus pensamientos a los cuales proyectar cada clase debería ir o si hay otro proyecto que debería 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ático 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 órdenes
5. Una clase que envía mensajes por correo electrónico a una acción del usuario

Answer 1

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

Answer 2

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

Quizás necesite cambiar el nombre de App.Data a App.Model (o algo similar) y tener un nuevo ensamblado App.DataAccess que se comunique con la base de datos (quizás implementando un patrón Repository). Habiendo hecho eso, dividiría las cosas de esta manera:

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 del todo seguro de lo que está haciendo la clase
4. Datos
5. Lógica de negocios

Answer 4

En realidad, creo que tienes cosas un poco fuera de una arquitectura estratificada 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 esta podría ser la fuente de la confusión entre las ubicaciones sugeridas de sus clases y su reacción a ellas en función de sus comentarios.

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

Más específicamente:

1. Las Preferencias de usuario son objetos comerciales, lo que los recupera es un objeto de capa de datos.
2. Los datos estáticos se asignan a un objeto de negocio (tabla o vista o algo), lo que accede al servidor externo es un objeto de capa de datos.
3. La titularidad del usuario es un objeto comercial, lo que lo recupera es un objeto de capa de datos.
4. Una tabla de pedidos es un objeto comercial
5. El correo electrónico es una actividad comercial, por lo que lo que se envía a las personas es un objeto comercial

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

DataAccessLayer

Esto incluiría mis TableAdapters y DataTables y fábricas fuertemente tipadas que convierten filas de mis DataTables en objetos comerciales en proyectos pre-LINQ. Usando LINQ esto incluiría mi DataContext y las entidades LINQ generadas por el diseñador.

BusinessLayer

Esto incluiría cualquier lógica comercial, 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 de clase parcial de mis entidades LINQ para implementar seguridad y validación junto con otras clases para implementar la lógica comercial.

Presentación

Estos son mis formularios web, básicamente la interfaz de usuario de la aplicación. Sí incluyo parte de la lógica de validación en los formularios como una optimización, aunque estos también están validados 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 conexiones a servicios web, que pueden estar directamente incluidos en el proyecto web, aunque lógicamente los componentes están realmente en BL / DAL.

Nota: Probablemente me mueva a MVC sobre 3 niveles una vez que ASP.NET MVC esté en producción. He hecho algunos proyectos personales en Ruby / Rails y realmente me gusta el paradigma de MVC para aplicaciones web.