我和我的开发团队都是传统的 .NET 开发人员，编写和维护许多用 C# .NET Web 表单(aspx 页面)和最近的 MVC 5 构建的应用程序。我们最近推出了一个新的基于 MVC 的 API，它充当用于提供 JSON 格式的参数请求数据并以可使用的形式提供该数据的 Web 服务。
我对 future 的轻量级 Web 应用程序非常感兴趣，其中所有繁重的工作都将在 API 中进行，而应用程序本身将是基本网页的集合。我们沿着使用 Visual Studio 编写的 MVC 解决方案来使用 API 的道路，但我们开始违背我们的旧习惯，在应用程序本身中编写业务逻辑，对每个应用程序进行碎片化等。
我向大家提出的问题是，当迁移到使用 JSON 生成 Web API 的轻量级前端 Web 应用程序(HTML 页面)时，哪些类型的功能会完全丢失？我认为安全性将是一个挑战，因为今天我们的 C# 应用程序依赖于 Web 用户的 Active Directory 帐户。还有哪些其他因素会阻碍我们？我们的 Web 应用程序是相对基本的，即调用和显示数据对象列表、查看/编辑/创建单个对象、报告等。我们试图摆脱每个新 Web 应用程序带来的复杂返工(目前我们有 60 多个)。我们正在尝试集中化，我喜欢 API 和轻量级 Web 前端的想法。
使用像 AngularJS 这样的东西来使用服务、反序列化对象并将它们写入现代引导 HTML 页面会很棒。理想情况下，我们甚至不会在 Web 应用程序中维护类和对象(当然它们会在 API 中)，但我们只需要一个已定义的对象属性列表，并将它们放置在需要的页面上。在创建和更新时，我们可以通过反序列化 HTML 表单中的数据并将数据推送回 API 来发回数据。
这可能吗？是什么阻碍了我们？在 C#、代码隐藏、ASPX 和 cshtml/html 帮助程序的世界中，我们最怀念的是什么？在这个基本的 HTML/Web API 平台上有什么是不可能的？
谢谢!!
最佳答案
这是一个大问题。
听起来您的开发团队张开双臂欢迎某些新技术，并且您喜欢您所看到的。良好的第一步(:但很明显，仍然有很多障碍需要克服，以及改进开发过程的方法(对所有团队来说都是一场持续的战斗)。您提到:
- 表示层的业务逻辑
- 碎片化+普遍的坏习惯
这些似乎与您的主要问题相切，但都是好问题。您考虑过Code Reviews作为接受拉取请求到版本控制的工作流程的一部分？您是否有诸如 DRY、KISS 等代码标准可以用来客观地衡量这些拉取请求？您是否有一个明确定义的架构(例如 Onion Architecture )，以便所有代码在代码中都有一个明确的位置？
回到您的主要问题:
- 安全性(即事件目录)
- 可重用代码(主要使用列表和数据对象[基本查询])
- 不想在 web 应用中维护类/对象
- 限制？我们能做我们想做的事吗？
我绝不是高级 .NET 开发人员，所以也许其他人可以提供更好的想法，但这是我的:
我认为您会发现很少的限制，但这将要求您和您的团队解决许多人可能没有遇到过的新问题。
你提到不使用模型(只是属性)，但我会把你推向另一个方向。我使用的应用程序通常具有以下内容:
- 域对象(为您的数据库建模)
- 数据传输对象 (DTO)
- View 模型(由 DTO 和 View 模型属性组成)
所有这三个都在后面的代码中维护，并且通过 AutoMapper 促进从域 -> DTO 和返回的传输。
我们还认识到，我们的大多数应用程序都是由关键域对象的基本 CRUD 操作组成的。所以...我们创建了一个基本 View 模型，其中包含一个 List 和一个 DetailDto(表单/单个对象)，其中我们操作 CRUD 的每个对象都充当 SPA。
为了安全起见，我们使用 authorization filters and the identity project 。这为我们提供了所需的安全级别，但听起来您还有其他担忧，但遗憾的是我没有资格回答。
我们仍然使用帮助程序，尤其是对于复杂的组件，但我们构建它们的方式使它们能够与我们的前端数据绑定(bind)框架很好地配合。
有点啰嗦。请随时要求澄清或提出其他问题。希望这至少有一点帮助!
关于c# - 调用 HTTP Web 服务的轻量级前端应用程序的优缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32491761/