我们有一个 ASP 经典 ERP（非常大的应用程序），我们想使用 ASP.NET 重写它。
我正在寻找一种组织应用程序的方法，以便我们能够将每个程序/网页（超过 400 个）彼此分开。每个程序都需要独立，因为许多开发人员会同时处理该项目。
Visual Studio 似乎为每个程序集创建一个 DLL，所以我想知道用每个 DLL 一个项目来创建一个庞大的解决方案是否是一个好主意。
例如。 :
这样，我们就能够单独部署每个程序，而无需更改其他程序。我们还有超过一千个 DLL 需要管理......
对于大规模应用来说，这似乎是一个很好的解决方案吗？ 大家有更好的主意吗？
源代码控制的发明正是为了让多个开发同时在大型解决方案上工作。我确实很欣赏拥有可以独立部署的组件的价值，但随着需要维护的独立组件的数量接近成百上千，也许这个价值就消失了？
将应用程序分成单独的表示/业务逻辑/DAL DLL 在每个模块的基础上确实有意义，但通常在每个页面的基础上并不有意义。
考虑应用程序的不同功能区域，这些区域可能共享代码并从那里开始（每个区域一组项目）。
对我来说，这似乎是一场巨大的、难以控制的噩梦。
我参与了几个大型 .Net 项目，最有效的方法是使用某种源代码控制，以及直接支持模型（数据库）的类，例如 JeffN825。
项目根目录下的文件夹可以帮助您逻辑地拆分“/Customers”、“/Orders”等
如果你想为你的班级制作单独的项目，这也已经完成了很多。有一个包含所有数据库对象的单独项目。为业务逻辑创建另一个项目。如果您觉得需要，实际上可以创建几个业务逻辑项目“CustomerBO”、“OrderBO”等。
但是管理超过 1000 个 dll 及其相关网页...这将是一场噩梦。
我认为问题是问为每个页面的每一层都有一个单独的 DLL 是否是一个好的体系结构，但事实并非如此，如果没有其他原因，Visual Studio 更有可能在尝试加载 100 个时爬行停止单独的项目（一想到这会做什么，以及维护所有这些 DLL 是多么不可能），我就不寒而栗。现在，更合理的解决方案是为每一层提供一个 DLL，并将每个页面的代码分离到不同的文件中，并使用源代码控制系统。这将允许开发人员共享代码，即使是最糟糕的源代码控制系统。如果您的源代码控制系统具有良好的分支/合并支持（即不是 SourceSafe），例如 TFS、SVN、Git，那么即使担心人们同时处理同一个文件，您也不必担心，然后您可以按功能而不是页面来组织代码。我大胆地从这个问题中猜测，可能有大量的重复代码可以通过打破与 Web 代码的严格连接并重用代码来简化并更容易维护。令人惊讶的是代码将会减少多少。您可以在 UI 端执行相同的操作，明智地使用用户控件来封装共享功能。另外，从 ASP 迁移到 .NET，您还可以选择 SiteMap 控件之类的东西，这也应该减少代码占用量。