重数据应用程序 silverlight vs mvc vs asp.net

发布于 2024-11-18 01:01:12 字数 864 浏览 8 评论 0原文

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

事实上问题是，这个应用程序可以归类为重数据应用程序，又名业务应用程序。

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

在使用的前两年里，我们没有注意到这个问题，但到了这段时间结束时，我们收到了越来越多关于应用程序性能的投诉。

我们过去和现在仍然使用 ADO.NET 和存储过程，这些存储过程是为 CRUD 操作（获取、列表、删除、插入、更新 SP）生成的，因此，如果我们要分离每年的数据，我们必须重新设计这些自动存储过程。生成的 SP 在数据访问层中进行了所需的修改，并且由于层中没有实际的分离，我们无法通过简单的方法进行修改，因此第一个即将推出的解决方案是进行一些数据库增强以平衡如此巨大的数据流量，但问题到现在为止大约6个月再次加息。

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

使用Web应用程序而不是Windows应用程序，因此我们将能够使用服务器的全部功能，并最大限度地减少连接流量
重新设计应用程序，以便它能够处理年末，不要获取所有数据，使用更好的 ORM 而不是旧的融合 ADO .NET，但坚持在 Windows 中表单和相同的应用程序

并根据时间框架（多少有限），团队成员（2个，都有很好的Windows，Web开发经验），我现在无法做出决定，我担心Windows应用程序修改可能需要比预期的。

你能给我建议吗？

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

原文

we've been using a custom made ERP application for more than 4 years, actually there were some bad design issues which affected the performance for the application right now.

in fact the problem is, this application can be classified as heavy-data application, aka business application.

the biggest bad design issues, is that we are getting the whole data for a particular business unit, and assign it for controls, or keep it in memory (like ArrayLists, Generic Lists), and give the user the flexibility of navigation and full application speed response.

in the first 2 years of usage, we didn't notice the problem, but by the end of that period, we are getting complaints, more and more about the performance of the application.

We were and still using ADO.NET, with stored procedures, which is generated for CRUD operations (Get, List, Delete, Insert, Update SPs), so if we are going to separate each year's data, we've to redesign those auto generated SPs with the required modifications in the data access layer, and with the fact that there were no actual separation in layers, we are not able by easy means to do that modification, so the first upcoming solution is to do some database enhancements to balance this huge data traffic, but the problem raises again for about 6 Months by now.

so we think this is the time to correct our mistakes (very late decision), but how could we do this? we end up with these solutions:

Use web application rather than windows application, thus we'll be able to use our server's full power, and minimizes the traffic for the connection
Redesign the application so that it takes care of Year Endings, don't get all data, use better ORM rather than old fusion ADO.NET, but stick in windows forms, and same application

and according to time frame (limited some how), team members (2, both have good experience in windows, web development), I'm not able to take the decision right now, I'm afraid that windows application modifications could take longer time than expected.

can you advice me?

I'm using C# 4.0, ASP.NET web forms, (MVC newbie).

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

烧了回忆取暖 2024-11-25 01:01:12

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

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

也就是说，您需要在 GUI 中拥有一个当前客户，然后才能进行操作填充 OrderHeaders 关系，并且仅当用户单击 GUI 中的特定订单标题时，您才会获取订单详细信息数据。关键是，ADO.NET 可用于执行此操作 - 您不必为了更加节约地处理断开连接的数据集而放弃应用程序中的所有内容。

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

If the database itself is quick, as you've indicated in your response to my comment, then, as you have suggested, you must reduce the amount of data populating the DataSet.

Although ADO.NET uses a "disconnected" model, the developer still has control over the select-query that is used to populate each table/relation in the DataSet. A hypothetical example: suppose you had 5000 customers in your CUSTOMERS table in the database. You might populate the CUSTOMERS table in your DataSet like this:

             select * from CUSTOMERS order by customername

or like this:

            select id, customername from CUSTOMERS order by customername

The order-headers table could be populated like this:

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

that is, you would need to have a current customer in the GUI before you'd populate the OrderHeaders relation, and you would fetch the order-detail data only when the user clicks on a particular order-header in the GUI. The point is, that ADO.NET can be used to do this -- you don't have to abandon everything in the app in order to be more parsimonious with the disconnected dataset.

How much data would be fetched by the client, and more importantly, when the data are fetched by the client, is completely under developer control regardless of whether it's Silverlight, WinForms, or ASP.NET. Now, if your ERP application was not efficient, retrofitting efficiency may be difficult. But you don't have to abandon ADO.NET to achieve efficiency, and simply choosing another data-layer technology will not itself bring you efficiency.

回复收藏 0 原文

~没有更多了~