调用 HTTP Web 服务的轻量级前端应用程序的优缺点

Question

我和我的开发团队都是传统的 .NET 开发人员，编写和维护许多以 C# .NET Web 表单（aspx 页面）和最近的 MVC 5 构建的应用程序。我们最近建立了一个新的基于 MVC 的 API，它充当Web 服务，用于以 JSON 格式提供参数请求的数据并以可消耗的形式提供此数据。

我对开发轻量级 Web 应用程序非常感兴趣，所有繁重的工作都将在 API 中完成，而应用程序本身将是基本网页的集合。我们走上了使用 Visual Studio 编写的 MVC 解决方案来使用 API 的道路，但我们开始打破我们的旧习惯，在应用程序本身中编写业务逻辑，对每个应用程序进行分段等等。

我的问题是，当迁移到使用 JSON 生成 Web API 的轻量级前端 Web 应用程序（HTML 页面）时，哪些类型的功能会完全丢失？我想安全性将是一个挑战，因为今天我们的 C# 应用程序依赖于 Web 用户的 Active Directory 帐户。还有哪些其他项目会阻碍我们？我们的 Web 应用程序是相对基础的，即调用和显示数据对象列表、查看/编辑/创建单个对象、报告等。我们试图摆脱每个新 Web 应用程序带来的复杂返工（我们目前有 60 多个）。我们正在尝试集中化，我喜欢 API 和轻量级 Web 前端的想法。

使用 AngularJS 之类的东西来使用服务、反序列化对象并将它们写入现代 Bootstrapped HTML 页面会很棒。理想情况下，我们甚至不会在 Web 应用程序中维护类和对象（当然它们会在 API 中），但我们只需要一个已定义的对象属性列表并将它们放置在需要的页面上。在创建和更新时，我们可以通过反序列化 HTML 表单中的数据并推回 API 来发回数据。

这可能吗？什么阻碍了我们？在 C#、代码隐藏、ASPX 和 cshtml/html 助手的世界中，我们最想念什么？在这个基本的 HTML/Web API 平台中什么是不可能的？

谢谢！！

Answer 1

这是一个大问题。

听起来您的开发团队张开双臂欢迎一些新技术，并且您喜欢您所看到的。良好的第一步（：但很明显，仍有许多障碍需要克服，以及改进开发过程的方法（所有团队的持续战斗）。您提到：

1. 表示层中的业务逻辑
2. 碎片化 + 一般的坏习惯

这些似乎与您的主要问题相去甚远，但却是很好的问题。您是否考虑将Code Reviews 作为接受拉取请求到您的版本控制的工作流程的一部分？你有没有可以用来客观地衡量这些拉取请求的代码标准，例如 DRY、KISS 等？您是否有明确定义的架构（例如Onion Architecture），以便所有代码在代码中都有一个明确的位置？

回到你的主要问题：

1. 安全（即活动目录）
2. 可重用的代码（主要使用列表和数据对象 [基本的 crud]）
3. 不想在 webapp 中维护类/对象
4. 限制？我们可以做我们想做的事吗？

我绝不是高级 .NET 开发人员，所以也许其他人可以提供更好的想法，但这是我的：

我认为您会发现很少有限制，但这需要您和您的团队解决许多人可能没有经验的新问题。

您提到不使用模型（仅使用属性），但我会将您推向另一个方向。我使用的应用程序通常具有以下内容：

• 域对象（为您的数据库建模）
• 数据传输对象 (DTO)
• 视图模型（由 DTO 和视图模型属性组成）

所有三个都在后面的代码中维护，并且使用 AutoMapper 促进了从 Domain -> DTO 和返回的传输。

我们还认识到，我们的大多数应用程序都包含对关键域对象的基本 CRUD 操作。所以...我们创建了一个基础视图模型，它有一个 List 和一个 DetailDto（表单/单个对象），我们在其中操作 CRUD 的每个对象都充当一个 SPA。

为了安全，我们使用authorization filters and the identity project。这为我们提供了所需的安全级别，但听起来您还有其他问题，我完全没有资格回答。

我们仍然使用帮助器，尤其是对于复杂的组件，但我们已经将它们构建为与我们的前端数据绑定框架很好地配合。

有点啰嗦。随时要求澄清或其他问题。希望这至少有一点帮助！

Answer 2

我想到的一件事是可重用性。使用 MVC，您可以使用局部视图来组织重复的代码块。虽然您可以使用 Angular 实现某些目标，但使用纯 HTML 页面可能无法完全实现。