我正面临着一项艰巨的任务，开始重新考虑我们最大的asp.net网站，该网站由asp经典创建，然后移植到asp.net VS2003，然后移植到asp.net VS2005上。代码是旧学校，所有业务逻辑和数据访问都可以在.aspx.cs文件中找到。好消息是，它正在运行A-Ok。
现在我的问题是，是否有关于如何重构asp.net代码的指导原则？ 如： - 我是否需要为重构代码创建单独的类，还是应该将app_code用于重构代码的新文件？ - 重构代码结构......等等。
答案 0 :(得分：2)
我建议您首先将业务逻辑提取到单独的类中 - 不要担心它们如何命名类，或者另一个结构是否可能更好。只需完成它，经常测试，以确保你没有破坏任何东西。稍后你可以决定逻辑应该在哪些类中，并且可以重构它以将它放在那里。
我提出建议的主要原因之一是，一旦业务逻辑分离，您就可以更轻松地针对该逻辑创建一整套单元测试。在开始重构以清理结构之前，您希望进行单元测试。只要单元测试成功，您就可以确定您的重构没有破坏任何内容。
这将为您（以及您的管理层）提供创建单独数据访问层等所需的信心。
答案 1 :(得分：0)
嗯，你显然想要创建某种数据访问层，你可以将它作为一个单独的项目构建。
因此，从文件后面的代码中获取所有数据访问[ADO]代码，并引用数据访问层。
随意使用App_Code，但不要过度使用它。在App_Code中放置太多类可能会减慢构建时间。
任何通用/实用程序类，也可以自由放入自己的类库项目。
这应该让你开始。
答案 2 :(得分：0)
我建议您首先将代码隐藏文件中的代码最小化。这些应具有检索用户输入，验证，与其他类交互以及提供输出所需的最少代码。所有的实际工作都应该在其他地方完成。
您可以创建一个业务层（一个单独的类库）来包含所有真实代码，您的前端将与之交互并委派给它们。此时，您可以尝试添加一些集成测试，以确保业务层中的组件按预期工作。
通过集成测试，进行一些重构以确保关注点分离，并遵循单一责任原则。此时添加单元测试应该不难。
如果您有数据访问代码，那么您肯定希望在代码隐藏之外。数据库处理应该至少在您的业务层中完成，或者更好的是，特定于数据库的代码应该在一个单独的层中，并通过业务层使用。