ASP.NET Web 应用程序 - 1 页中 5000 行代码 - 可以接受吗？
我正在构建一个基于 ASP .NET 2.0 (C#) 的 Web 应用程序，该应用程序主要用于内部网使用，即在组织的局域网内使用。
关于用户界面，我需要选择两种方法。
构建一个 1 页 Web 应用程序，其中包含大量 ASP .NET AJAX 1.0 控件（模式弹出窗口）来显示分类内容，否则这些内容将进入单独的 .aspx 页面。
使用传统方法并构建多个页面。
1 页 UI 看起来和感觉都非常酷。 但是，我对其可扩展性持怀疑态度。
同意该应用程序旨在通过 LAN 使用，但由于它是一个 Web 应用程序，因此如果客户愿意，可以通过互联网使用它。
由于 1 页 UI，单个 .aspx 页面中已经有大约 2600 行代码，代码隐藏 (.aspx.cs) 中有另外 1600 行代码，
这将增长到最多 10,000 行代码（.aspx 中有 10,000 个，.aspx.cs 中有 10,000 个）。 所以我需要知道 - 对于基于 ASP .NET 的页面来说多少才算太多 - 2600 + 1600 行代码对于 Intranet 和 Internet 访问是否合适？ 10,000 行代码怎么样？ 瓶颈是什么？ 这种单页面方法可以吗？还是我需要退回到传统的多页面方法？
I'm building an ASP .NET 2.0 (C#) based web application, which is primarily intended for intra-net use, i.e. to be used inside an organization's Local Area Network.
With respect to the User Interface, there are 2 approaches which I need to choose from.
Build a 1 page web app, with lots of ASP .NET AJAX 1.0 controls (modal popups) to show categorized content which would otherwise have gone into a separate .aspx page.
Use the traditional approach and build multiple pages.
The 1 page UI looks and feels very cool. However, I have doubts with respect to its scalability.
Agreed that the application is intended for use over a LAN, but since it is a web app, it could potentially be used from over the internet if the client wanted to.
Owing to the 1 page UI, there's already around 2600 lines of code in the single .aspx page and another 1600 lines of code in the code-behind (.aspx.cs)
This is going to grow - to at most - 10,000 lines of code (10,000 in .aspx and 10,000 in .aspx.cs). So I need to know - how much is too much for an ASP .NET based page - is 2600 + 1600 lines of code okay for Intranet AND Internet access? How about 10,000 lines of code? What is the bottle-neck? Is this single-page approach okay or do I need to fall back to the traditional multiple-page approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
从表面上看，这对我来说听起来像是一个可怕的解决方案（我敢打赌你的 DAO 嵌入在视图中），但如果不检查实际代码就不可能说。
至少您有意识寻求另一种意见和其他选择……您对可扩展性的担忧是有道理的。
仔细考虑适当地对您的应用程序进行分层...您的整体解决方案如何在支持 WML 视图方面达到“适当分层”的解决方案？
At face value, it sounds like a horror solution to me (I'll bet your DAO is embedded in the view) but it's impossible to say without reviewing the actual code.
And atleast you had the sense to seek another opinion, and other options... Your concerns regarding scalability are valid.
Think carefully about layering your application approriately... How would your monolithic solution stack up to a "properly layered" solution with regards also supporting a WML view?
到底多少才算是太多，我们无法回答。 这不仅仅是数量的问题，代码的质量也很重要。 可以肯定地说的一件事是，如果将大量代码放入单个页面中，维护代码就会遇到问题。 例如，如果您是多个开发人员在开发该应用程序，您将需要非常频繁地合并源代码控制系统中的更改，而不是对单独的文件执行简单的更新。
即使您将应用程序实现为单个页面，我也强烈鼓励您将后面代码上的单独行为封装到单独的类中，这些类是根据页面需要创建和使用的。 但我会亲自设计应用程序，以便单独的行为也进入单独的页面。
How much that is too much is impossible to answer. It's not just about the amount, the quality of the code matters as well. The one thing that can be said with certainty is that if you put large amounts of code into a single page, you will have issues maintaining the code. If you are more than one developer working on the application you will for instance need to merge changes in your source control system very frequently, instead of performing simple updates of separate files.
Even if you would implement the application as a single page I would strongly encourage you to encapsulate separate behaviours on the code behind into separate classes that are created an used as needed by the page. But I would personally design the application so that separate behaviours went into separate pages as well.
我很惊讶没有人提到 ViewState。 我认为如果您最小化 ViewState 的大小（使用 ascx 控件并动态加载它们），那么设计良好的“一页解决方案”就可以了。
I'm surprised nobody's mentioned ViewState. I think if you minimize the size of the ViewState (using ascx controls and loading them dynamically), then a well designed "one page solution" is fine.
单个页面上 10k 的代码太多了（它可能运行得很好），但是你能维护这些代码吗？ 我不确定有人可以:)
10k of code on a single page it too much (it might run fine) but can you maintain this code ?? i m not sure anybody can :)
你的数字离“OK”还很远。 事实上，老实说，它们是灾难性的...
首先将尽可能多的不同概念填充到用户控件中。 然后创建一些有状态的解决方案，以便可以将用户控件动态加载到页面的区域中。
Your numbers are WAY FAR from "OK". In fact they're disastrous to be honest with you...
Start out by stuffing as much as possible of your different concepts into UserControls. Then create some stateful solution to make it possible to dynamically load UserControls into regions of your page.
我的一些页面的 .aspx 上有 2K 行，代码隐藏文件中有 10,000 多行。 我有许多功能在网站的其他地方没有使用，并且依赖于一些视图状态信息。 在我看来，在这种情况下，我认为这是一种性能提升，而不是要求服务器搜索另一个页面上的功能等。我认为有时，你只需要做你必须做的事情，它就是这样。 只是尝试使您的代码尽可能高效。
I have some pages with 2K lines on the .aspx and 10,000+ in the code behind file. I have many function that are not used anywhere else on the site and rely on some viewstate info. In my mind, and this situation, I think this is a performace boost rather than asking the server to search out functions on another page etc. I think sometimes, you just have to do what you have to do and it is what it is. Just try to make your code as efficient as possible.
在我说出我想说的话之前，我想声明我认为这不是一个好主意。 任何长度为 5k 或 10k 行的类 (ASP.NET) 都需要重构。
这里有很多评论一直说你的下载时间太长。 仅仅因为您的 .aspx 文件嵌入了 5k 行代码或代码隐藏文件中包含 5k 行（或两者），这并不意味着您的下载时间会因此而变得很长。 这些代码行在服务器上编译和执行，它们不会传递到客户端。 因此，代码行数与下载大小之间没有直接关系。
Sayed Ibrahim Hashimi
我的书：Microsoft 构建引擎内部：使用 MSBuild 和 Team Foundation Build
Before I say what I intend to say I would like to state that I do not think this is a good idea. Any class (ASP.NET) or not that is 5k or 10k lines long needs to be refactored.
There are a lot of comments here that keep stating that your download times will be too long. Just because you have an .aspx file that has 5k lines of code embedded or 5k in a code behind file (or both) this doesn't mean that your download times will be significant just because of this. Those lines of code are compiled and executed on the server, they are not passed to the client. So there is not a direct relationship between # of lines of code to download size.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
不管像这样令人难以置信的臃肿的单页面会增加下载时间，维护起来绝对是一场噩梦。 我同意布拉德的观点，单页方法是不对的。 我想不出任何方法来证明单个代码隐藏中的 10k+ 行是合理的。
Regardless of the increased download time for an incredibly bloated single page like that, it would be an absolute nightmare to maintain. I agree with Brad, the single page approach is not right. And I can't think of any way to justify 10k+ lines in a single codebehind.
如果您需要在一个网页中拥有所有功能，我建议将代码移动到单独的 ascx 控件中，并将所有 ascx 合并到一个 aspx 中
if you need to have all the functionality in a single web page, I suggest moving the code into separate ascx controls and combining all the ascx's in one aspx
您始终应该考虑那些会尝试理解您的代码并在您之后修改您的应用程序的人。 不管怎样，我认为一页——这绝对是不可接受的。 不存在任何“传统的多页面方法”。 如果您的应用程序包含不同的操作，它应该是“多页”
You always shoud think about people who will try to uderstand your code to modify your app after you. Anyway I think one page - this is definitely not acceptable. There is no any "traditional multiple-page approach". If your application contains different actions it should be "multiple-page"
不行，按功能或部分将内容分成不同的文件。
这就是用户控件有用的地方。
如果此页面具有业务逻辑，请将其放入 BLL 中。
与 DAL 相同。
将所有内容与 DAL、BLL 和用户控件分开后，所有内容都应该更易于维护。
Not ok, split things up into different files by functionality or section.
This is where user controls come in usefull.
If this page has business logic place this in a BLL.
Same with DAL.
After you have split everything up with DAL, BLL and user controls everything should be a lot more maintainable.