设计组织良好且模块化的 ASP.NET 应用程序的最佳方法
我正在尝试为我们的产品开发考虑一个网络应用程序开发框架。我想构建一个 ASP.NET 应用程序，其中包含许多子模块。我的要求是这样的：
应用程序将是一套不同的模块，如 CRM、Bugtracker、库存管理、财务管理等。
每个模块应该有自己的DLL。
一个项目应该用于应用程序的外部容器（如框架），并且该项目应该将解决方案中的所有其他模块（Web 应用程序类型）引入外部容器。 （比如我们有 HTML 中的框架）。因此，我们只会在一天结束时发布外部容器 Web 应用程序，所有其他 Web 应用程序项目都将通过该应用程序进行访问。
我希望每个模块都有单独的 DLL，这样当我部署控制整个套件的单个 DLL 时，我就不需要担心应用程序崩溃。
我不确定我的想法是否朝着正确的方向。我正在寻找的最终结果是一个维护良好、组织良好且模块化的 Web 应用程序套件。
它是 ASP.NET Web 表单，而不是 MVC。我将使用VS2010进行开发。
做到这一点的最佳方法是什么？
编辑：
术语“外部容器”意味着它就像一个母版页，具有指向各个模块的链接，并且各个模块并不总是在同一个项目中。它们可以是同一解决方案下的单独项目。我的印象是，到最后，我将只发布该项目，并且它将带来各种模块。
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
事实上，我认为最好的方法是不过度架构的方法。我担心您似乎在没有充分理由的情况下生成整体架构。
这些都是新模块吗？然后开始写第一个。使用适用于单个模块的最佳实践。
然后写第二个。您会发现您想要使用在第一个模块中已经编写的内容。伟大的。这就是重构的目的。将这些内容重构为一个或多个“库”项目，重新运行所有单元测试，然后继续第二个模块。
重复直到完成所有模块。
在此过程结束时，如果您需要所概述的那种架构，那么您就会拥有它。如果您需要的更少，那么您拥有的就会更少，并且您将不会花时间创建与现实世界需求无关的架构。
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
我不会说这是“最好的方法”，但我建议您查看 Dot Net Nuke （ DNN）来获得一些想法。它最初是 Microsoft 分发的旧的“I Buy Spy”入门 Web 项目，用于展示 ASP.NET 项目，并从那里开始腾飞。
编辑：
您可以使用 DNN 来完成此操作。它们在 DNN 和 Drupal 中也称为“模块”。
是的，这是一个好主意。您会在 DNN 和 Drupal 等多个内容管理系统中看到这种情况。这样，同一网站的所有实现都不需要安装所有模块。
我们有一个重要的网站，用于托管我们收费的“服务即解决方案”应用程序（如果您不是精算师或会计师，您将不会听说过它）。过去几年的首席开发人员使用 DotNetNuke 的早期版本作为模型来重构他被允许更改的应用程序部分。
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
You can do this with DNN. They're also called "modules" in DNN and Drupal.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
就像其他人建议的那样，DNN 可能会适合您想要做的事情。如果您想完全自然地推出自己的产品，我会转向容器“框架”和一堆用户控件（.ascx）的某种组合。该容器可以像带有菜单的母版页一样简单。根据您希望设计的灵活性，您可以预制许多不同的页面，每个页面托管一个不同的控件（根据您的需要单独的 dll）。如果您希望它更加动态一点，您可以拥有一个内容页，该内容页将在运行时动态地将所需的用户控件加载到其中。同样，这只是一种通用方法，可能是对 DNN 实施方式的 30000 英尺视角。
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
以您的公司/产品命名主要项目，并保持简短。您可能需要一两个库项目来支持它 - 这些项目将包含诸如 之类的日常常见逻辑错误报告、Web 实用程序方法等。
接下来，选择您想要的 子项目（我不喜欢这个特定上下文中的术语模块）并将其添加到您的解决方案中。无论您是重用现有项目，还是最好从头开始，您最终都会将该项目中的所有通用逻辑移至您的库中。
冲洗并重复。也许看一下类似的 Sueetie 项目，其中包括几个子项目，如 CMS、博客、日历、论坛、以下
文章在 MSDN 上被标记为“过时”，但我仍然认为您应该看一下：
构建解决方案和项目
此外，模式和实践小组提供了类似的内容：
在 Team Foundation 源代码管理中构建项目和解决方案
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control