轻量级前端应用程序调用HTTP Web服务的利弊

Question

我和我的开发团队都是传统的.NET开发人员，他们编写和维护许多以C＃.NET Web表单（aspx页面）和最近的MVC 5结构化的应用程序。我们最近站起来了一个基于MVC的新API，该API充当在JSON中提供参数请求的数据，并以可消耗形式提供此数据。

我对追求轻量级的Web应用程序非常感兴趣，因为它会在API中进行所有繁重的工作，而应用程序本身就是基本网页的集合。 我们沿用了用Visual Studio编写的MVC解决方案来使用API​​的方法，但是我们开始违背我们的旧习惯，在应用程序本身中编写业务逻辑，对每个应用程序进行分段，等等。

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

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

这可能吗？ 阻碍我们前进的是什么？ 我们将从C＃，代码落后，ASPX和cshtml / html帮助器世界中最想念的是什么？ 在这个基本的HTML / web API平台中不可能实现什么？

谢谢！！

Answer 1

这是一个大问题。

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

1. 表示层中的业务逻辑
2. 支离破碎+普遍的不良习惯

从您的主要问题来看，这些似乎是切线，但它们是好问题。 您是否考虑过将代码审查作为将拉取请求接受到版本控制中的工作流的一部分？ 您是否具有诸如DRY，KISS等之类的代码标准，可以用来客观地衡量这些拉动请求？ 并且您是否有一个明确定义的架构（例如Onion Architecture ），以便所有代码在代码中都有清晰的位置？

回到您的主要问题：

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

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

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

您提到没有使用模型（只是属性），但我会向另一个方向推。 我使用的应用程序通常具有以下功能：

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

保留所有这三个代码，并通过AutoMapper方便地进行从Domain-> DTO和向后的传输。

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

为了安全起见，我们使用授权过滤器和身份项目 。 这使我们获得了所需的安全级别，但听起来您还有其他担忧，而我完全没有资格回答。

我们仍然使用辅助程序，特别是对于复杂的组件，但是我们以使它们可以与前端数据绑定框架很好地协作的方式来构建它们。

有点粗鲁。 随时要求澄清或其他问题。 希望这至少可以有所帮助！

Answer 2

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