DataTable Wrapper 或如何将 UI 与业务逻辑解耦 [英] DataTable Wrapper or How to decouple UI from Business logic
问题描述
我正在使用网络表单、C#、Asp.net.众所周知，在这个模型中，UI 和业务逻辑经常混杂在一起.如何有效地将它们分开?
I am using web forms, C#, Asp.net. As we all know, in this model UI and business logic are often mixed in. How do I separate these effectively?
我想使用的例子是:我有一个 GridView 和一个 DataTable(GridView 绑定到 DataTable，DataTable 是从存储过程提供的).
The example I would like to use is: I have a GridView and a DataTable (GridView binds to the DataTable and DataTable is fed from the stored procedure).
我希望将 GridView(UI)和 DataTable(业务逻辑)解耦.
I would like the GridView (UI) and DataTable (business logic) to be decoupled.
为 DataTable 编写包装器值得吗?是否有经过验证和测试的实用模式，您可以推荐遵循?
Is it worth it to write an wrapper for DataTable? Are there practical patterns that have been proved and tested that you could recommend to be followed?
如果有经验的人可以解释一下，那就太棒了.而且，作为最后一点，我想说 ASP MVC 现在不是一个选项，所以不推荐它.
If someone with experience could shed some light, that would be awesome. And, as a final note I would like to say that ASP MVC is not an option right now, so don't recommend it.
我的数据库访问层返回一个数据表.请注意，我必须使用此数据库层，因为这是公司政策.
My database access layer returns a DataTable. Note that I HAVE to use this database layer as this is a company policy.
推荐答案
我最近经历了这个，同时从我们的 UI 层解耦了很多相同的东西.
I went through this recently while decoupling much the same thing from our UI layer.
您可以在此处和
在我看来，DataTable不代表业务逻辑.具体来说，它是直接从数据库中提取的数据.业务逻辑将这些数据转化为真正有用的业务对象.
In my opinion, A DataTable does not represent business logic. Specifically, it's data pulled directly from the database. Business logic turns that data into a truly useful business object.
然后，第一步是将 DataTable 与业务对象分离.
The first step, then, is to decouple the DataTable from the Business object.
您可以通过创建组成数据表和数据表集合的对象和 List 来实现这一点，然后您可以创建一个显示这些对象的 ListView.我在上面发布的链接中介绍了后面的步骤.前面的步骤和下面一样简单:
You can do that by creating objects and List<object> that make up DataTables and Collections of DataTables, and then you can make a ListView that displays those Objects. I cover the latter steps in the links I posted above. And the former steps are as easy as the following:
- 创建一个代表您的对象的类.
- 遍历您的 DataTable(或 DataSet，或者您检索数据的任何方式)并将这些字段推送到该对象的属性中(或那个
List)； - 将该列表返回给 Gridview 或 ListView 以显示.
这样您的 ListView 或 Gridview 就不会与您检索数据的方法紧密耦合.如果您决定稍后从 JSON 查询或 XML 文件中获取数据，会发生什么情况?然后你必须把它构建到那里.
This way your ListView or Gridview won't be tightly coupled to the method that you are retrieving your data. What happens if you decide to get your data from a JSON query or a XML file later on? Then you'd have to build this into there.
有多种方法可以从数据库中获取数据，在这里我无法一一介绍.我假设您已经知道如何从数据库中检索数据，如果您不知道，还有 相当多的链接可以关注.假设您已连接到数据库，并且正在使用 SQLDataReader 来检索数据.我们会在那里接机.
There are multiple methods to get data from a database, there's no way I can go through all of them here. I assume that you already know how to retrieve data from a database, and if you don't, there are quite a few links to follow. Let's pretend you've connected to the database, and are using an SQLDataReader to retrieve data. We'll pick up there.
Foo
----
id
Name
Description
方法如下:
private void FillDefault(SqlDataReader reader, Foos foo)
{
try
{
foo.id = Convert.ToInt32(reader[Foo.Properties.ID]);
foo.Name = reader[Foo.Properties.NAME].ToString();
if (!string.IsNullOrEmpty(
reader[Foo.Properties.DESCRIPTION].ToString()))
foo.Description =
reader[Foo.Properties.DESCRIPTION].ToString();
else foo.Description = string.Empty;
}
catch (Exception ex)
{
throw new Exception(
string.Format("Invalid Query.
Column '{0}' does not exist in SqlDataReader.",
ex.Message));
}
}
一旦发生这种情况，您可以通过在以 SQLDataReader.Read() 函数为目标的 while 循环中执行该过程来返回一个列表.
Once that happens, you can return a list by going through that process in a while loop that targets the SQLDataReader.Read() function.
一旦你这样做了，让我们假设你返回的 Foo 是一个列表.如果你这样做，并按照我上面给出的第一个链接，你可以用 List 替换 Dictionary 并获得相同的结果(与次要差异).Properties 类只包含数据库中的列名，因此您可以在一处更改它们(以防万一).
Once you do that, let's pretend that your Foo being returned is a List. If you do that, and follow the first link I gave above, you can replace Dictionary<TKey, TValue> with List<T> and achieve the same result (with minor differences). The Properties class just contains the column names in the database, so you have one place to change them (in case you were wondering).
您始终可以插入中间对象.在本例中，我将在 DataTable 和 UI 之间插入一个业务层，并且我已经讨论了上面的操作.但是 DataTable 不是业务对象；它是数据库的可视化表示.您无法将其传输到 UI 层并将其称为解耦.他们说您必须使用 DataTable，他们是否说您必须将该 DataTable 传输到 UI?我无法想象他们会这样做.如果这样做，那么您将永远不会脱钩.在 DataTable 和 UI 层之间总是需要一个中间对象.
You can always insert an intermediate object. In this instance, I'd insert a Business Layer between the DataTable and the UI, and I've discussed what I'd do above. But a DataTable is not a business object; it is a visual representation of a database. You can't transport that to the UI layer and call it de-coupled. They say you have to use a DataTable, do they say that you have to transport that DataTable to the UI? I can't imagine they would. If you do, then you'll never be de-coupled. You'll always need an intermediate object in between the DataTable and the UI layer.
这篇关于DataTable Wrapper 或如何将 UI 与业务逻辑解耦的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
