ASP.NET WebForms应用程序的最佳体系结构

我已经为客户端编写了一个ASP.NET WebForms门户。该项目是经过改进的，而不是从一开始就进行了适当的计划和组织。因此，所有代码都在同一项目中混在一起，没有任何层次。客户端现在对功能很满意，因此我想重构代码，以便对发布项目充满信心。由于似乎有许多不同的方法来设计体系结构，所以我想对最好的方法提出一些意见。

功能性

门户允许管理员配置HTML模板。其他关联的“合作伙伴”将可以通过向其网站添加IFrame代码来显示这些模板。在这些模板中，客户可以注册和购买产品。已经使用WCF实现了API，该API允许外部公司也可以与系统连接。管理员部分允许管理员配置各种功能并查看每个合作伙伴的报告。系统将发票和电子邮件通知发送给客户。

当前架构

它当前正在使用EF4读取/写入数据库。EF对象直接在aspx文件中使用。在我编写站点时，这促进了快速开发，但是像这样将它与UI紧密耦合在一起可能使它保持不可接受。特定的业务逻辑已添加到EF对象的部分类中。

问题

重构的目标是使站点可扩展，易于维护和安全。

哪种架构最适合此？请说明每层中应该包含的内容，是否应使用DTO的/ POCO / Active Record模式等。
是否有一种健壮的方法来自动生成DTO / BO，以便尽管有额外的层，也可以轻松实现将来的任何增强功能？
将项目从WebForms转换为MVC是否有益？

— 堆人
source

提前发布，经常发布。我建议，如果您没有明显的业务问题（例如，这是不安全的），您的客户可能不太在意。也许您应该清理一点（确保它是可移植的），然后发布，然后将其作为长期计划-转变为MVC或类似的东西。

— gahooa

不要仅仅因为已有的项目技术就将其更改为新的xyz技术，特别是如果您的项目按原样运行时。如果它正在工作，请不要破坏它。企业不关心代码。最后，功能才是最重要的。

— NoChance 2012年

好的，这是真的，但是我担心的是，一旦发布，将更加难以重构，因为当赌注高得多时，有可能将其破坏。因此，我们将陷入无法维护且难以调试的代码之中。我很想学习/转换为MVP，但看起来工作量太大。到目前为止，我刚刚将其转换为DAL，Domain，UI层，这些层感觉更加井井有条，但仍然允许在项目年轻时不可避免地需要RAD。如果有必要，有一天我可以扩展到MVP或MVC，我有足够的时间来学习这一切的原理。

— 堆栈人

仍然令人感到混乱的是：1）UI中的EF对象（UI层中文件的代码背后）

— 堆栈人

（2）必须在DAL层中使用的扩展EF对象中的业务逻辑（没有意识到部分类必须在同一程序集中）（3）UI层中的aspx.cs文件中的业务逻辑。但是，在体系结构方面似乎经常会妥协，但这无疑是向前迈出的一步。我觉得这对于第一版是可以接受的，随着时间的流逝，我们可以重新评估我们的方法。谢谢大家的帮助。取得一些指导是很好的，因为这个领域太主观了。

— 堆叠人

Answers:

ASP.NET MVP模式是长期 ASP.NET Webforms应用程序的最佳体系结构。它与“关注点分离”概念一起起作用，这实际上是MV *模式背后的趋势。

关于这个问题，为什么要使用它？-这篇文章中有详细介绍-ASP.NET MVP

— 尤苏波夫
source

问题是，将项目重构为MVC需要大量的工作...如果我将其保留为具有域层（代码优先，POCO），数据访问层（仅数据库上下文）和UI的WebForms应用，将会您认为这是可接受的生产设计吗？我想以后可以考虑将其转换为MVC。

— 2012年

嗯，这是MVP（模型视图呈现器）模式，而不是MVC（模型视图控制器）。

— 尤苏波夫

哦，对不起-我看错了。谢谢-我将介绍MVP设计。

— 堆叠人

没问题，我希望您能找到想要的东西：）

— Yusubov

转换为MVP似乎也将是一个重大变化。客户希望很快发布，那么您认为上述体系结构DAL / DA / UI（尽管不如MVP理想）对于这种类型的应用程序可以接受吗？然后在发布之后，我们可以考虑在v2中迁移到MVP。

— 2012年

将MVP模式用于逻辑和UI分离，因此在将来，您可以重用现有的逻辑，转向其他UI技术
使用BL和DAL之间的存储库模式，以便您可以重用业务逻辑来更改为任何RDBS
为BO和DAL带来单独的层（Dll），从而最大程度地减少了维护。

— 阿鲁纳恰兰姆
source

不知道为什么有人不赞成这个问题。老实说，这是最简洁的答案。+1

— Greg Burghardt

正如ElYusubov所说，MVP模式可能很棒。

关键概念是从背后的代码中剥离大部分或所有逻辑。逻辑不应绑定到页面。如果您需要重复使用一页中的逻辑，该怎么办？您将很容易复制和粘贴。如果您这样做，那么您的项目将变得可维护。

因此，对于初学者来说，开始将代码背后的逻辑重构，并将其放在业务层中。如果您设法将所有逻辑排除在代码之外，那么您可以实现必要的接口以成为真正的MVP。

另外，请确保您的数据访问与业务逻辑分开。创建一个数据层，并在那端开始重构。由于您使用的是EF4，因此问题不大，因为EF应该已经将此端分开。您应该能够轻松地将所有EF文件移动到另一个项目，并只需添加对需要它的项目的引用即可。另外一个好处是，您可能需要在其他项目中引用您的数据模型。

为避免不知所措，一次重构一点。每当您触摸一段代码时，请考虑对其周围的代码进行重构。如果这样做，随着时间的流逝，您的项目将变得更加可维护。

编辑

您询问有关使背后的代码继承业务逻辑类的问题。无法完成此操作，因为“ is-a”页面后面的代码。C＃不允许多重继承，因此代码隐藏类不能同时是页面和自定义对象。您需要从概念上分离出逻辑。您的背后代码中的代码可能正在做许多不同的事情。一堂课只能做一件事，只能做一件事。尝试考虑如何从概念上讲出现有功能。例如，假设您有一个注册页面，并且正在收集用户信息。您可能有一个称为“注册”的按钮，以及一个与该按钮相关联的click事件。在这种情况下，您将保存用户信息并进行所需的任何处理。您可以创建一个Registration对象来处理所有逻辑。

这不仅可以实现更清晰的分隔，而且还可以成为自记录代码的一种方式。当某人阅读您的代码时，他们会看到您调用了Registration对象，因此您确切地知道正在发生什么。

如果您要严格遵循MVP模式，则无需将参数传递给Registration对象，其背后的代码将实现一个接口。接口的实现实质上将所有视图对象（文本字段等）映射到接口。例如，公共字符串FirstName {get {return txtFirstName.Text; }}

完成后，您可以将页面传递给Regisration对象

Registration.RegisterUser（this）;

并且此RegisterUser方法将接口作为参数

公共布尔RegisterUser（IUser用户）{user.FirstName ...}

公共接口IUser {公共字符串FirstName; }

如果此MVP听起来令人困惑，则只需专注于重构并知道所有目的就是最大程度地重复使用代码。重复自己再没有了。那是DRY的负责人。

— 编码器
source

感谢您的有用提示。是的，我当然对此有点不知所措。在我看来，MVC将是最佳使用模式，但MVP将更容易实现，并且将成为下一个最佳模式。我一直在文件后面使用代码，因此总是为如何将业务逻辑与表示法分离而烦恼……所以我应该能够将我的.aspx.cs文件实质上移到域层，并在aspx中有一个继承声明。？当然，以3层结尾将使我对发布第一个版本感到满意-然后可以从那里进行改进。

— 堆栈人

我将在回答中回应您的评论。如果您认为我的回答有用

— 编码器