关于如何在 .NET 的 N 层应用程序中使用强类型数据集的问题
我需要一些关于 ADO.NET 中由 Visual Studio 生成的强类型数据集的专家建议。以下是详细信息。先感谢您。
我想编写一个 N 层应用程序,其中表示层采用 C#/windows 表单,业务层是 Web 服务,数据访问层是 SQL db。
因此,我为此使用了 Visual Studio 2005,并在解决方案中创建了 3 个项目。
项目 1 是数据访问层。在此,我使用 Visual Studio 数据集生成器创建强类型数据集和表适配器(为了测试,我在 Northwind 的客户表上创建了它)。数据集称为NorthWindDataSet,里面的表是CustomersTable。
项目 2 的 Web 服务仅公开 1 个方法,即 GetCustomersDataSet。这使用project1库的表适配器来填充数据集并将其返回给调用者。为了能够使用 NorthWindDataSet 和表适配器,我添加了对项目 1 的引用。
项目 3 是一个 win 表单应用程序,它使用 Web 服务作为引用并调用该服务来获取数据集。< /p>
在构建此应用程序的过程中,在 PL 中,我添加了对项目 1 中上面生成的 DataSet 的引用,并在表单的加载中调用 Web 服务并将从 Web 服务接收到的 DataSet 分配给该数据集。但我收到错误:
无法隐式转换类型 'PL.WebServiceLayerReference.NorthwindDataSet' 到“BL.NorthwindDataSet”e:\My 文档\Visual Studio 2008\Projects\DataSetWebServiceExample\PL\Form1.cs
两个数据集相同,但因为我添加了来自不同位置的引用,所以我认为出现了上述错误。
因此,我所做的就是向项目 3(UI)添加对项目 1(定义数据集)的引用,并使用 Web 服务获取数据集并分配到正确的类型,现在当项目 3(定义数据集)有网络表单)运行,我得到以下运行时异常。
系统.InvalidOperationException: XML 文档中有错误 (1, 第5058章) ---> System.Xml.Schema.XmlSchemaException: 元素的多重定义 'http://tempuri.org/NorthwindDataSet.xsd:Customers' 导致内容模型变成 模糊的。内容模型必须是 形成这样在验证期间 元素信息项序列, 直接包含的粒子, 间接或隐含地其中 尝试验证每个项目 按顺序依次可 未经审查而唯一确定的 该内容或属性 项目,并且没有任何信息 关于其余的项目 序列。
我认为这可能是因为一些交叉引用错误。
我的问题是,有没有一种方法可以使用 Visual Studio 生成的数据集,以便我可以在所有层中使用相同的数据集(以便重用),但将表适配器逻辑分离到数据访问层,以便前端通过网络服务从所有这些中抽象出来?
如果我手动编写代码,我就会失去数据集生成器提供的优点,而且如果稍后添加列,我需要手动添加它等,所以我想尽可能多地使用 Visual Studio 向导。
I need some expert advice on strong typed data sets in ADO.NET that are generated by the Visual Studio. Here are the details. Thank you in advance.
I want to write a N-tier application where Presentation layer is in C#/windows forms, Business Layer is a Web service and Data Access Layer is SQL db.
So, I used Visual Studio 2005 for this and created 3 projects in a solution.
project 1 is the Data access layer. In this I have used visual studio data set generator to create a strong typed data set and table adapter (to test I created this on the customers table in northwind). The data set is called NorthWindDataSet and the table inside is CustomersTable.
project 2 has the web service which exposes only 1 method which is GetCustomersDataSet. This uses the project1 library's table adapter to fill the data set and return it to the caller. To be able to use the NorthWindDataSet and table adapter, I added a reference to the project 1.
project 3 is a win forms app and this uses the web service as a reference and calls that service to get the data set.
In the process of building this application, in the PL, I added a reference to the DataSet generated above in the project 1 and in form's load I call the web service and assign the received DataSet from the web service to this dataset. But I get the error:
Cannot implicitly convert type
'PL.WebServiceLayerReference.NorthwindDataSet'
to 'BL.NorthwindDataSet' e:\My
Documents\Visual Studio
2008\Projects\DataSetWebServiceExample\PL\Form1.cs
Both the data sets are same but because I added references from different locations, I am getting the above error I think.
So, what I did was I added a reference to project 1 (which defines the data set) to project 3 (the UI) and used the web service to get the DataSet and assing to the right type, now when the project 3 (which has the web form) runs, I get the below runtime exception.
System.InvalidOperationException:
There is an error in XML document (1,
5058). --->
System.Xml.Schema.XmlSchemaException:
Multiple definition of element
'http://tempuri.org/NorthwindDataSet.xsd:Customers'
causes the content model to become
ambiguous. A content model must be
formed such that during validation of
an element information item sequence,
the particle contained directly,
indirectly or implicitly therein with
which to attempt to validate each item
in the sequence in turn can be
uniquely determined without examining
the content or attributes of that
item, and without any information
about the items in the remainder of
the sequence.
I think this might be because of some cross referenceing errors.
My question is, is there a way to use the visual studio generated DataSets in such a way that I can use the same DataSet in all layers (for reuse) but separate the Table Adapter logic to the Data Access Layer so that the front end is abstracted from all this by the web service?
If I have hand write the code I loose the goodness the data set generator gives and also if there are columns added later I need to add it by hand etc so I want to use the visual studio wizard as much as possible.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果我是你,我会远离数据集。它们在很大程度上是该问题的 .NET 2.0 解决方案,但也不是一个很好的解决方案。
我会使用实体框架作为数据层 - 它们不存在数据集所存在的问题,包括您所看到的问题。数据集必须同时存在于两个世界中——XML 和关系,而且它们并不总是适合。实体框架可以构建只需要符合继承和关联等标准编程概念的实体模型。
通过 Web 服务传输时,实体框架的问题也较少。您应该使用 WCF 来完成所有新的 Web 服务工作(Microsoft 现在认为 ASMX Web 服务是“遗留技术”),但即使使用 ASMX Web 服务,EF 实体也会相当干净地传输。 .NET 3.5 中存在一些相对较小的问题,但这些问题已在 .NET 4.0 中得到解决。
I would stay away from datasets if I were you. They are very much a .NET 2.0 solution to the problem, and they weren't a very good solution, either.
I would use Entity Framework as a data layer - they do not have the issues a DataSet has, including the one you're seeing. A DataSet has to live in both worlds - both XML and relational, and they don't always fit. Entity Framework can build you entity models that need only conform to standard programming concepts like inheritance and association.
Entity Framework also has fewer issues when transferred over web services. You should use WCF for all your new web service work (Microsoft now considers ASMX web services to be "legacy technology"), but even with ASMX web services, EF entities will transfer fairly cleanly. There are some relatively minor issues in .NET 3.5, but those are addressed in .NET 4.0.
如果您不想为 EF 重写应用程序或添加 DTO,并且您知道架构是相等的,则可以通过 Web 服务在表示层中设置数据集架构。
您的数据集架构充当对象模型。不漂亮但应该能胜任。
话虽这么说,如果这是一个新项目,我同意其他答案 - 避免数据集。
If you don't want to rewrite your app for EF or add DTOs, and you know the schemas are equal, you could set the data set schema in your presentation layer via the web service.
Your data set schema acts as the object model. Not pretty but should do the job.
With that being said, if this is a new project, I agree with the other answers - avoid data sets.
我在这里支持 John,我们在 N 层应用程序中使用 EF v1.0,当然它有自己的问题,但您可以获得可以通过服务推送的常规对象。不过我建议(如果您使用 EF1 而不是 EF4,它能够将其对象公开为 POCO 的)有一个单独的 DTO 对象层,它将我从 DAL 映射到 DO 对象,并使用 DTO 通过服务进行传输。 确实非常棒
还可以考虑使用 .NET RIA 服务,它们在 DTO< 上 @sb: /a>,在 EF 上,快速浏览 RIA 服务,
关于带有数据集的 DTO 的旧文章,你想做什么。
I'd back up John here, we use EF v1.0 in N-tiered app and of course it has it's own problems but you get regular objects which you can push through service. However I'd advise ( in case you go with EF1 not EF4 which has ability to expose it's objects as POCO's) to have a separate layer of DTO objects which would me mapped to DO objects from you DAL, and use DTO for transfering through service. Also consider using .NET RIA services, they are really fantastic
@sb: on DTO, on EF, quick overlook of RIA services,
old article on DTO with datasets, what you are trying to do.