我需要编写一个客户端-服务器解决方案。该服务器将执行计划的操作，并从SQL DB向客户端提供数据。
客户端尚未完全定义，但是它将向服务器请求并为用户显示数据，并将数据传回以保持持久性。
整个解决方案是处理实体（用户，产品等及其相关属性）。
在我看来，服务器和客户端都需要意识到这些实体，以便有效地在代码中对其进行操作，而不必解压JSON和重复代码。
我的问题是，我是否应该创建一个包含代表这些实体的模型（类或结构）的类库，而这些模型同时被客户端和服务器端项目引用？
否则，是否有一些标准的方法来构建这样的解决方案？
到目前为止，我有一个客户端，一个服务器（基于ASP.NET 2）和一个包含实体模型以及一些数据访问逻辑的类库。客户端和服务器项目都引用类库。有一天，我已经开始怀疑自己的方法太笨拙。
我将使用C＃使用VS2019。
答案 0 :(得分：0)
这实际上不是一个非常适合于StackOverflow的问题，它旨在解决特定的代码/技术问题。
可以在客户端和服务器中使用相同的模型（实体），但是我强烈建议将客户端模型（视图模型）与域模型分开。 （实体）的原因是：
客户很少需要或应该公开每个域字段和关系。从服务器向客户端发送模型涉及序列化。这可能会导致性能问题或错误，因为串行器“接触”属性并希望延迟加载它们，或者增加了急于加载所有内容的成本。否则会导致不完整的模型，其中卸载的关系保留为空。 （不是因为没有，因为它们没有被加载）客户端模型应该被精简为仅适合客户端需要查看的数据，并以可以使用的方式进行格式化。最终，这将向客户端和后端传送更多的数据。保持网上的有效载荷尽可能小。
将实体从客户端传递到服务器时，安全性可能成为问题。您的UI可能只允许用户以非常特殊的方式更改一些值，但诱惑可能是采用该实体，将其附加到数据库上下文并更新它。 （1行更新）但是，从客户端发送的该实体很容易被浏览器篡改，这可能会导致您不希望/不允许的更改。 （即更改FK关系）
充其量，这可以允许陈旧的数据覆盖，在该记录发送给客户端之后所做的更改将在客户端到处提交其更改时被无声覆盖。不要信任来自客户端的数据，尤其是在“节省时间”的前提下。更新请求应验证传入的数据，并在更新允许的值之前重新加载Entity以检查行版本之类的东西。
启用视图模型可以使用EF支持的一种称为Projection的技术来完成。可以使用.Select进行手写，也可以利用Automapper及其ProjectTo方法之类的工具轻松地将实体和Linq表达式转换为简单，可哑的可序列化视图模型。当视图模型返回服务器时，您只需按ID从数据库加载实体和关联，并在验证步骤和SaveChanges之后更新值以保持不变。