c# - Pregunta sobre cómo usar un fuerte conjunto de datos tipeados en la aplicación N-tier para.NET
visual-studio ado.net (3)
Necesito algunos consejos expertos sobre conjuntos de datos tipeados sólidos en ADO.NET generados por Visual Studio. Aquí están los detalles. Gracias de antemano.
Quiero escribir una aplicación de N niveles donde la capa de presentación está en C # / formularios de Windows, Business Layer es un servicio web y Data Access Layer es SQL db.
Entonces, utilicé Visual Studio 2005 para esto y creé 3 proyectos en una solución.
el proyecto 1 es la capa de acceso a los datos. En esto, he usado el generador de conjuntos de datos de Visual Studio para crear un conjunto de datos y un adaptador de tabla robustos (para probar, he creado esto en la tabla de clientes en northwind). El conjunto de datos se llama NorthWindDataSet y la tabla dentro es CustomersTable.
el proyecto 2 tiene el servicio web que expone solo 1 método que es GetCustomersDataSet. Esto usa el adaptador de tabla de la biblioteca project1 para completar el conjunto de datos y devolverlo a la persona que llama. Para poder usar el NorthWindDataSet y el adaptador de tabla, agregué una referencia al proyecto 1.
El proyecto 3 es una aplicación de formularios para ganar y utiliza el servicio web como referencia y llama a ese servicio para obtener el conjunto de datos.
En el proceso de creación de esta aplicación, en el PL, agregué una referencia al DataSet generado anteriormente en el proyecto 1 y en la carga del formulario llamo al servicio web y asigno el DataSet recibido del servicio web a este conjunto de datos. Pero me sale el error:
No se puede convertir implícitamente el tipo ''PL.WebServiceLayerReference.NorthwindDataSet'' a ''BL.NorthwindDataSet'' e: / My Documents / Visual Studio 2008 / Projects / DataSetWebServiceExample / PL / Form1.cs
Ambos conjuntos de datos son iguales, pero debido a que agregué referencias de diferentes ubicaciones, creo que estoy obteniendo el error anterior.
Entonces, lo que hice fue agregar una referencia al proyecto 1 (que define el conjunto de datos) al proyecto 3 (la IU) y utilicé el servicio web para obtener el conjunto de datos y asignar el tipo correcto, ahora cuando el proyecto 3 (que tiene el formulario web) se ejecuta, obtengo la excepción de tiempo de ejecución siguiente.
System.InvalidOperationException: hay un error en el documento XML (1, 5058). ---> System.Xml.Schema.XmlSchemaException: la definición múltiple del elemento '' http://tempuri.org/NorthwindDataSet.xsd:Customers '' hace que el modelo de contenido se vuelva ambiguo. Un modelo de contenido debe formarse de modo que durante la validación de una secuencia de elemento de información de elemento, la partícula contenida directa, indirecta o implícitamente con la que intentar validar cada elemento en la secuencia a su vez pueda determinarse de manera única sin examinar el contenido o atributos de ese artículo, y sin ninguna información sobre los artículos en el resto de la secuencia.
Creo que esto podría deberse a algunos errores de referencia cruzada.
Mi pregunta es, ¿hay alguna manera de usar los DataSets generados por Visual Studio de modo que pueda usar el mismo DataSet en todas las capas (para reutilizar) pero separe la lógica del Adaptador de Tabla de la Capa de Acceso a Datos para que la interfaz sea abstraído de todo esto por el servicio web?
Si tengo mano, escribo el código, pierdo la bondad que proporciona el generador de conjuntos de datos y también, si hay columnas añadidas más tarde, debo agregarlas a mano, etc., así que quiero usar el asistente de estudio visual tanto como sea posible.
Mi pregunta es, ¿hay alguna manera de usar los DataSets generados por Visual Studio de modo que pueda usar el mismo DataSet en todas las capas (para reutilizar) pero separe la lógica del Adaptador de Tabla de la Capa de Acceso a Datos para que la interfaz sea abstraído de todo esto por el servicio web
Si no desea volver a escribir su aplicación para EF o agregar DTO, y sabe que los esquemas son iguales, puede establecer el esquema del conjunto de datos en su capa de presentación a través del servicio web.
Project3DataSet.ReadXmlSchema(
new StringReader(Project2WebService.GetCustomersDataSetSchema()));
[WebMethod]
public string GetCustomersDataSetSchema()
{
return new Project1DataSet().GetXmlSchema();
}
Su esquema de conjunto de datos actúa como el modelo de objetos. No es bonito, pero debería hacer el trabajo.
Dicho esto, si se trata de un proyecto nuevo, estoy de acuerdo con las otras respuestas, evite los conjuntos de datos.
Me gustaría hacer una copia de seguridad de John aquí, utilizamos EF v1.0 en la aplicación N-tiered y, por supuesto, tiene sus propios problemas, pero obtienes objetos regulares que puedes pasar por el servicio. Sin embargo, aconsejaría (en caso de que vaya con EF1 no EF4 que tenga la capacidad de exponer sus objetos como POCO) tener una capa separada de objetos DTO que me asignaría a objetos DO de su DAL, y usaría DTO para transferirlos a través del servicio . También considere usar los servicios .NET RIA, son realmente fantásticos
@sb: en DTO , en EF , visión rápida de los servicios de RIA , antiguo artículo sobre DTO con conjuntos de datos , lo que estás tratando de hacer.
Me mantendría alejado de los conjuntos de datos si fuera usted. Son en gran medida una solución .NET 2.0 al problema, y tampoco fueron una solución muy buena.
Usaría Entity Framework como una capa de datos: no tienen los problemas que tiene DataSet, incluido el que está viendo. Un DataSet tiene que vivir en ambos mundos, tanto XML como relacionales, y no siempre se ajustan. Entity Framework puede construirle modelos de entidades que solo necesitan ajustarse a conceptos de programación estándar como herencia y asociación.
Entity Framework también tiene menos problemas cuando se transfiere a través de servicios web. Debe usar WCF para todo su nuevo trabajo de servicio web (Microsoft ahora considera que los servicios web ASMX son "tecnología heredada"), pero incluso con los servicios web ASMX, las entidades EF se transferirán de forma bastante limpia. Hay algunos problemas relativamente menores en .NET 3.5, pero esos se abordan en .NET 4.0.