0

我们已经使用定制的 ERP 应用程序超过 4 年，实际上有一些糟糕的设计问题影响了应用程序的性能。

事实上问题是，这个应用程序可以归类为大数据应用程序，也就是业务应用程序。

最大的糟糕设计问题是，我们正在获取特定业务单元的全部数据，并将其分配给控件，或将其保存在内存中（如 ArrayLists、Generic Lists），并为用户提供导航和完整应用程序的灵活性速度响应。

在前 2 年的使用中，我们没有注意到问题，但是到那个时期结束时，我们收到了越来越多关于应用程序性能的投诉。

我们曾经并且仍在使用带有存储过程的 ADO.NET，它是为 CRUD 操作（Get、List、Delete、Insert、Update SP）生成的，所以如果我们要分离每年的数据，我们必须重新设计那些自动在数据访问层生成具有所需修改的 SP，并且事实上没有实际的层分离，我们无法通过简单的方式进行修改，因此第一个即将到来的解决方案是进行一些数据库增强以平衡这个巨大的数据流量，但问题再次出现大约 6 个月。

所以我们认为现在是纠正错误的时候了（很晚的决定），但我们怎么能这样做呢？我们最终得到了这些解决方案：

  • 使用 web 应用程序而不是 windows 应用程序，因此我们将能够使用我们服务器的全部功能，并最大限度地减少连接流量

  • 重新设计应用程序以处理年终问题，不要获取所有数据，使用更好的 ORM 而不是旧的融合 ADO.NET，但坚持使用 Windows 窗体和相同的应用程序

并且根据时间框架（有限的一些方法），团队成员（2个，都有良好的windows，web开发经验），我现在无法做出决定，我担心windows应用程序修改可能需要更长的时间时间超出预期。

你能给我建议吗？

我正在使用 C# 4.0、ASP.NET Web 表单（MVC 新手）。

4

1 回答 1

2

如果数据库本身很快，正如您在对我的评论的回复中指出的那样，那么，正如您所建议的，您必须减少填充 DataSet 的数据量。

尽管 ADO.NET 使用“断开连接”模型，但开发人员仍然可以控制用于填充 DataSet 中每个表/关系的选择查询。一个假设的例子：假设您在数据库的 CUSTOMERS 表中有 5000 个客户。您可以像这样在 DataSet 中填充 CUSTOMERS 表：

             select * from CUSTOMERS order by customername

或像这样：

            select id, customername from CUSTOMERS order by customername

order-headers 表可以这样填充：

            create proc getOrderHeaders4Customer
            @customerid int
            as
            select * from ORDERHEADER where customerid = @customerid

也就是说，在填充 OrderHeaders 关系之前，您需要在 GUI 中有一个当前客户，并且只有当用户单击 GUI 中的特定订单标题时，您才会获取订单详细信息。关键是，可以使用 ADO.NET 来执行此操作——您不必放弃应用程序中的所有内容，以便对断开连接的数据集更加节俭。

客户端将获取多少数据，更重要的是，当客户端获取数据时，无论是 Silverlight、WinForms 还是 ASP.NET，都完全由开发人员控制。现在，如果您的 ERP 应用程序效率不高，改造效率可能会很困难。但是你不必为了效率而放弃ADO.NET，简单地选择另一种数据层技术本身并不会给你带来效率。

于 2011-07-03T16:02:53.367 回答