我真的必须创建多个模型吗？答案

【问题标题】：Do I have to really create multiple models?我真的必须创建多个模型吗？
【发布时间】：2019-10-04 12:36:56
【问题描述】：

历史上的 MS 堆栈开发人员。

我已承诺对以下堆栈进行重组

 angular -> ms web.api2 -> C# business objects -> sql server

年纪大了，我从需求开发数据库并使用 Codesmith 生成业务逻辑层。（是的，我听说过实体框架。甚至尝试过一次）。

当我拥抱 Angular 和 Web API 2 时

我发现 Angular 想让我在前端写一个模型。这似乎只是一个数据结构，我什至无法为其添加辅助方法

所以我也经常编写一个带有辅助方法的类，它采用模型的实例。有点丑，但它确实结合了结构和逻辑。

我发现 Web API2 想让我写一个模型。这似乎又只是一个数据结构。我正在探索动态数据类型，但实际上这并没有给我太多帮助。我没有写一个类，而是写了一个映射函数。

问题是这样的：

有没有办法让每个类的 3 个以上副本分布在堆栈中？ Codesmith 是一个非常强大的代码生成器……它可以生成多个文件……但是……

如果它只有几个数据成员和 3 个位置，我可以复制粘贴编辑并完成它。

在我看来，现在致力于在 3 个不同的环境中保持数据结构同步正在为大量工作做好准备。

在过去的 15 年中，我一直在尝试将尽可能多的代码放入可继承类的框架中，这样我就可以保持 DRY。

我错过了什么吗？有什么可以推荐的模式吗？

[我知道这不是为 SO 量身定做的问题，但它是所有聪明人购物的地方。如果您觉得有必要这样做，请给我投反对票。]

【问题讨论】：

我感受到你的痛苦。我们的应用程序存在于一个面向数据库的框架中，该框架比 EF 早了相当长的一段时间。我们有代码生成器为服务器端的 .NET+.NET Core 和客户端的 .NET+Angular 生成模型对象。至少对于 .NET 事物，我们可以将它们生成为“partial class blahblah {...}”，以便我们可以在单独的非生成文件中添加方法和其他逻辑。在 Angular 中，我们将逻辑放入包装 POCO 集合的服务中。
感谢您的回复。 woudl/EF 会缓解这种情况，还是只是让它与众不同？
EF 只关心 EF。 EF 曾经（据我所知仍然是）不适合我们，因为它需要一个表/视图来执行其 Select 操作，而我们正在处理的数据库框架通过存储过程来控制所有内容以强制执行行级安全性.作为一项心理练习，我玩弄了通过SET CONTEXT_INFO ... 传递我们的用户访问令牌并在内部视图中使用context_info() 来维护RLS 的想法，但从来没有足够的时间来实际充实它——在EF 中你仍然需要修改所有SQL请求在 EF 生成的代码之前注入这个 SQL 的 sn-p。

标签： c# sql-server angular asp.net-core-webapi dry

【解决方案1】：

并不完全熟悉 CodeSmith 如何生成它的类，但如果它们只是可以很好地序列化的普通旧 CLR 对象，您可以让 WebApi 将它们直接返回到您的 Angular 应用程序。有些纯粹主义者会对此不以为然，但根据应用程序，可能会有理由。

然后，在 Angular 的世界中，您有几个选择，这取决于您的要求/理由和您的应用程序 - 同样，纯粹主义者肯定会不赞成某些选择。

创建与来自服务器的内容相匹配的类（更正确的方法）
将所有内容都视为“任何”，失去类型安全性，并且只在需要时访问属性，即不要创建模型。（显然不太正确的方法）
找到一个代码生成工具，该工具将探索 API 端点以确定它们返回的内容，并为您生成 typescript 类。

就个人而言，使用实体框架，我（手动）创建我的 POCO 用于数据库交互，有一个 WebAPI 然后将发送回客户端的“视图”/DTO 类，以及 Typescript 中对象的定义，但我是控制狂，不喜欢生成的代码。

【讨论】：

感谢您的回复。我现在在 30 分钟内听过两次 POCO。比以往任何时候都多两倍！ en.wikipedia.org/wiki/Plain_old_CLR_object.
所以当你意识到 tshirts 不需要颜色时，它们需要 bodyColor 和 sleeveColor，你需要更新多少文件？
除了所有其他设计注意事项外，我必须更新我的 SQL 文件/实体框架迁移文件、我的 POCO、我的视图/dto、我的 Angular 类、我的角度视图，以及任何与设置“tShirt colour”交互的命令（我使用 CQRS 类型模式）。很多变化是不利的 - 好处是（除了 TypeScript 和 C# 类之间的断开连接），它都是类型安全的。编辑：通过类型安全，我的意思是编译时安全 - 如果我错过任何东西，它会在编译时告诉我
我发现自己不仅在 TypeScript 中创建与 C# 匹配的类，而且在到达客户端时拦截它们并将它们转换为 TypeScript 类的实际实例，以便我可以访问这些方法以及属性。这很痛苦，你会认为有一种方法可以在 TypeScript 中重用 C# 类，但是一旦你决定如何最好地处理它，每次都遵循这个过程就变得相当简单了。同样显而易见的是，我更有可能在 TypeScript 类上拥有方法，而不是在通常只是 DTO 的 C# 类上拥有方法。
@AndrewP，codeSmith 几乎可以生成您能想象到的任何文本文件。我用它从表定义中创建 vb.net 和 c# 类。如果我传入一个，我会尝试 Angular 中的结果。我希望标准序列化会与我的类一起挣扎。