在大型 ASP.NET 应用程序方面需要帮助

Question

我们有一个 ASP 经典 ERP（非常大的应用程序），我们想用 ASP.NET 重写它。

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

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

例如。 ：

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

对象实体的Customers.DLL

CustomersManager.DLL 用于业务逻辑

用于数据访问的CustomersData.DLL

这样，我们就可以在不改变其他程序的情况下单独部署每个程序。我们还要管理一千多个 DLL……

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

谢谢

Answer 1

我认为问题是问是否为每个页面的每一层设置一个单独的 DLL 是否是一个好的架构，如果没有其他原因，Visual Studio 很可能会在尝试停止时爬行停止加载 100 个单独的项目（我不禁想到那会做什么，以及维护所有这些 DLL 是多么不可能）。现在更合理的解决方案是为每一层都有一个 DLL，并将每个页面的代码分离到不同的文件中，并使用源代码控制系统。这将允许开发人员共享代码，即使是最糟糕的源代码控制系统。如果您的源代码控制系统具有像 TFS、SVN、Git 这样的不错的分支/合并支持（即不是 SourceSafe），那么即使担心人们同时处理同一个文件，您也不会真的，然后您可以按功能而不是页面组织代码.我冒昧地从这个问题中猜测，可能存在大量重复的代码，可以通过打破与 Web 代码的刚性连接和重用代码来简化和更容易维护。看到代码会减少多少，真是令人惊讶。你可以在 UI 端做同样的事情，明智地使用用户控件来封装共享功能。再加上从 ASP 迁移到 .NET，您还可以使用 SiteMap 控件之类的东西，这些控件也应该可以减少代码占用量。

Answer 2

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

我参与了几个大型 .Net 项目，效果最好的方式是，比如 JeffN825，使用某种源代码控制，以及直接支持您的模型（数据库）的类。

项目根目录下的文件夹可以帮助您在逻辑上拆分“/Customers”、“/Orders”等。

如果你想为你的班级制作单独的项目，那也做了很多。有一个包含所有数据库对象的单独项目。为业务逻辑创建另一个项目。如果您觉得需要“CustomerBO”、“OrderBO”等，请实际创建几个业务逻辑项目。

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

Answer 3

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

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

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