Buena arquitectura para aplicaciones de escritorio de 2 niveles (cliente-servidor) usando linq-to-sql

Question

Nuestra arquitectura actual - UI, BusinessLayer, DAL (generado linq-to-sql) .En la capa DAL, hemos agregado la lógica de validación para entidades en clase parcial. Estamos utilizando directamente entidades generadas por linq-to-sql en businesslayer (que es un grupo de clases - clase \ formulario). También, en estas clases bll, creamos consultas de linq a sql.

Creo que podríamos aplicar capas a la aplicación mejor en términos de patrón MVP, y tener clases de servicio que proporcionan datos usando linq-to-sql. ¿Qué opina? ¿Debo considerar el patrón de repositorio? ¿Sería eso un exceso?

Answer 1

¡Es una buena idea!

Su elección depende de su aplicación, pero estos son muchos problemas:

1) La transformación entre el modelo de base de datos de objetos y la aplicación del modelo de objetos puede ser mucho más difícil. En tales casos, es imposible implementar filtros en un modelo para la aplicación para que la consulta resultante se pueda trasmitir a SQL.

2) A menudo, como resultado de la toma de muestras necesario para obtener el resultado de la conexión (unión) de varias tablas, y no sólo los datos de una tabla

3) No todos los SQL-operaciones y funciones tienen su equivalente en LINQ

¿Qué pasa con Entity Framework? Por favor, no toques Entity Framework. ¡Es algo pesado y lento! :)

Prefiero el acceso clásico a los datos mediante el procedimiento almacenado y el acceso a los datos de MS Enterprise Library. Puedo usar el poder de SQL y la flexibilidad de mis propias entidades comerciales. Y, por supuesto, ¡rendimiento! El reverso de la medalla es más trabajo. Utilicé algunas herramientas para autogenerar objetos de acceso a datos y luego los corrigió cuando lo necesitaba.

Suerte!

Answer 2

Todas las cosas buenas en las que pensar, pero a medida que comiences por este camino, estoy seguro de que tendrás más preguntas que respuestas la mayor parte del tiempo.

Supongo que está utilizando Windows Forms cuando menciona Desktop y Linq-To-SQL, lo que le dará algunos desafíos para implementar algo como un patrón MVP.

Si bien hay frameworks MVP preconfeccionados para WinForms (MVC# viene a la mente), si no está desarrollando aplicaciones a gran escala, entonces puede comenzar con cuidado e implementar algunos de los conceptos usando su propio código.

La excelente serie de artículos de Jeremy Miller Build Your Own CAB es un gran recurso aquí, ya que puede sacar algunas de las primeras ideas de allí y obtener una separación de preocupaciones entre sus formularios (Presentación) y lógica comercial (Presentadoras y clases de servicio))

Jeremy usa principalmente un diseño de Controlador Supervisor en su trabajo (que me encanta), pero vale la pena mirar otros patrones como Passive View y Model-View-ViewModel (que está integrado en la forma de trabajar de WPF, así que vale la pena comprensión), para ver con qué se siente más cómodo.

En cuanto a su pregunta sobre clases de servicio o repositorios, creo que los dos niveles principales de lógica que querría son las entidades Presenter o ViewModel, y luego las entidades de Servicio debajo de las que pueden contener cosas como su Linq-To- Consultas SQL.Por lo tanto, es posible que ya tenga mucha lógica para su capa de Servicio allí, pero se trata más bien de refaccionarla en una forma consistente.

Answer 3

Parece que está en el camino correcto. Si tuviera una capa de servicio WCF, podría ejecutarla en proceso o a través de HTTP, lo que significa que podría soportar una aplicación tipo servidor cliente en lugar de presionar la base de datos desde el principio, pero realmente depende de su aplicación.

Answer 4

MVP puede ser difícil de entender para los desarrolladores, pero podría intentarlo.