¿Deben los objetos de Business Logic tener conocimiento de sus objetos de datos LINQ-to-SQL?

Question

He examinado varias preguntas similares, pero no vi ninguna que se aplicara directamente a mí, así que perdónenme si esto es un duplicado.

Para separar las preocupaciones, estoy tratando de asignar de alguna manera mis objetos comerciales con lógica a los objetos de datos LINQ to SQL en el archivo .dbml (bastante nuevo en este por cierto). Sin embargo, lo que parece es que mis objetos comerciales necesitarán saber sobre los objetos LINQ2SQL correspondientes. Leí este artículo acerca de tratar de usar POCO con un archivo de mapeo xml, y parece que es similar a lo que quiero, excepto que no tengo un mapeo individual de tablas a clases debido a una relación de muchos a muchos para la que necesitaba crear una tabla adicional.

Puedo encapsular bastante bien el acceso a los datos en mi lógica de negocios, de modo que el código que usa mis objetos de negocios no necesita saber nada sobre la base de datos, lo cual es bueno, pero la capa de negocios todavía está estrechamente unida al acceso de datos capa de tal manera que no podría cambiar el DAL sin cambiar mis objetos de capa empresarial o crear otros nuevos (que implementen las mismas interfaces) para diferentes proveedores de datos.

¿Cómo puedo desacoplar estas capas?

Answer 1

No estoy seguro si está vinculado a LINQ to SQL de alguna manera, pero lo que está tratando de lograr es prácticamente el valor predeterminado en NHibernate. Recomiendo echar un vistazo a NHibernate para ver si sería más fácil cambiar que luchar contra LINQ to SQL.

He descubierto que luchar contra una herramienta es casi siempre una mala idea.