需要有关大型ASP.NET应用程序的帮助

Question

我们想要使用ASP.NET重写ASP经典ERP（非常大的应用程序）。

我正在寻找一种组织应用程序的方法，以便我们能够将每个程序/网页（超过400个）彼此分开。每个程序都需要独立，因为许多开发人员将同时处理该项目。

Visual Studio似乎为每个程序集创建了一个DLL，所以我想知道每个DLL为一个项目制作一个巨大的解决方案是不是一个好主意。

实施例。 ：

Customers.aspx + Customers.aspx.vb（已编译）用于演示文稿

对象实体的Customers.DLL

用于业务逻辑的CustomersManager.DLL

CustomersData.DLL用于数据访问

这样，我们就可以单独部署每个程序而不改变其他程序。我们还有超过一千个DLL来管理...

对于大规模应用来说，它似乎是一个很好的解决方案吗？ 任何人都有更好的主意吗？

由于

Answer 1

源控制的发明正是为了让多个开发同时处理大型解决方案。我确实感谢拥有可以独立部署的组件的价值，但随着需要维护的独立组件数量接近数百和数千，这些价值可能会丢失吗？

将应用程序分离为单独的表示/业务逻辑/ DAL DLL在每个模块的基础上确实有意义，但通常不是基于每页。

考虑应用程序的不同功能区域，这些区域可能共享代码并从那里开始（每组都有一组项目）。

Answer 2

这对我来说似乎是一个巨大的无法控制的噩梦。

我参与了几个大型的.Net项目，并且最好的方式就像JeffN825一样，使用某种源代码控制，以及直接支持你的模型（数据库）的类。

项目根目录下的文件夹可以帮助您按逻辑分割“/ Customers”，“/ Orders”等。

如果你想为你的课程制作单独的项目，那也是相当多的。有一个包含所有数据库对象的单独项目。为Business Logic创建另一个项目。如果您觉得需要“CustomerBO”，“OrderBO”等，实际上会创建几个Business Logic项目。

但管理超过1000个dll及其相关网页......这将是一场噩梦。

Answer 3

我认为问题是询问是否为每个页面的每一层都有一个单独的DLL是一个很好的架构，它不是，如果没有其他原因，除了Visual Studio更可能不会爬行停止，因为它试图加载100个单独的项目（我不禁想到会做什么，以及维护所有这些DLL是多么不可能）。现在更合理的解决方案是为每个层创建一个DLL，并将每个页面的代码分成不同的文件并使用源控制系统。这将允许开发人员共享代码，即使是最糟糕的源代码控制系统。如果您的源代码控制系统具有良好的分支/合并支持（即不是SourceSafe），如TFS，SVN，Git，您甚至不必担心人们同时处理同一个文件，然后您可以按功能组织代码而不是页面。我想从这个问题中猜测，通过打破与Web代码的严格连接并重用代码，可能会有一些天文数字的重复代码可以简化并更容易维护。看到会有多少代码可能会令人惊讶。您可以在UI端执行相同操作，明智地使用用户控件来封装共享功能。再加上从ASP迁移到.NET，您可以选择SiteMap控件，这样可以减少代码占用空间。