混乱3层设计

我一直在审查3层设计的网络上的例子，我注意到，大多数样本返回数据集或数据表。让我感到困惑的是如果你宁愿返回一个泛型类型列表，以便在列表所基于的类型中使用属性或方法？例如，使用Name属性根据数据以特定方式连接各个字段，如果List绑定到表单上的控件，那么Name属性可以用作数据字段。如果你想在使用数据集或表时完成同样的事情，你必须从数据库中返回数据以达到同样的效果（我尽量不使用数据集或数据表，所以我可能对这个语句非常错误:)）混乱3层设计

让我感到困惑的部分是关于重新使用代码，对我来说似乎重用代码的唯一方法是将数据检索到数据集或数据表中，然后循环遍历数据并添加它到一个列表，这通常是3层的最佳实践，或者有没有办法做到这一点，没有数据集和数据表。

以下链接中的示例实质上演示了使用数据集或表格然后将其添加到对象，但我不得不问这是否是最佳做法？

http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET

感谢

来源

2013-01-12 obb-taurus

仅对小型项目使用'Datasets'或'DataTables'。它们不能很好地扩展并且有很多限制。链接中的'dbConnection'类是一个不好的例子，因为它不处理/关闭连接和其他一次性对象。 –

使用DataTable s是一个特定的dotnetism。其原因在于它们包含有关数据结构的元数据，这使得DataGrid（和其他此类组件）可以自动显示数据，而无需使用反射等。我的猜测是，这是对RAD的MS Access方法的传统之一，其意图是通过直接从SQL模式生成用户界面来使“业务人员”能够创建应用程序，本质上与分层设计相反。这种遗产似乎已经泄露到了h h中。

只要您愿意放弃RAD功能，使用“普通”数据结构并没有错，最近的趋势似乎也是为了摆脱这种折衷。（例如，使用Web Forms的强类型数据控件和MVC的模型绑定功能）。另外，更一般而言，MVC之前创建的代码项目文章在通用软件体系结构中并不是真正的智慧源泉。

来源

2013-01-12 19:10:55 millimoose

您应该如何携带您的数据完全取决于您的需求。

如果您从数据库检索数据并将其绑定到数据网格，数据集可能会为您提供完美的解决方案。如果你想要其他数据跟踪自己的更新状态的其他方法，你应该看看实体框架。如果您检索数据并通过Web服务发送数据以进行跨平台或跨域处理，则需要将数据加载到您自己的某些其他可序列化类中。

看看下面的文章。这是一个有点老，针对EF4，但它很好地总结了不同策略的优点和缺点。（有系列中的三篇文章，我建议你阅读所有）

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

来源

2013-01-12 19:14:19

我认为样品你发现所使用的数据表和数据集，因为它是一个简单的方法来显示3层设计。现在天Entity Framework已经在很大程度上取代了样本中提到的“数据访问层”。

在我写一个数据访问层的实体框架之前，我会返回一个我从数据库中构建的通用列表。要运行更新，删除或插入，我会将一个对象作为参数传递给方法，然后使用该对象的属性作为sql语句中的值。我更喜欢这样做，因为你提到的原因，但也因为它允许我相互独立地更改对象定义或数据库模式（或甚至使用不同的数据库）。

来源

2013-01-12 19:36:16

我还没有深入实体框架的领域，所以我现在使用DAL卡住了。你会有一个你使用列表的方式的例子吗？ –

@ obb-taurus真的不一样。实体框架主要返回自己的模型对象的IEnumerable，这足够接近'List'的目的。 – millimoose

一个示例需要几十行代码，这实际上不是再这样做的方式。我本质上是在编写一个ORM（对象关系映射器），但现在有几个ORM可以为您节省大量时间，而且比自己编写一个节省更少。从数据库获取通用或强类型集合的最佳实践是使用实体框架，LINQ to SQL或NHibernate。 –

回答

相关问题