我正在构建一个附加到数据库的 Web 服务。我打算将 EntityFramework ORM 用于我的持久层。我使用了数据库优先的方法，根据我对信息的最有效组织方式来设计我的表格。
ORM 在 C# 中为我生成了一些数据实体，但现在我需要通过 web 服务将该对象数据的子集发送到我的客户端。
示例：假设我有一个用户表：-Id -Username -Company -Password -Email -AdminNotes
并说我希望用户能够请求其他用户的信息，但不是所有信息。因此，在这种情况下，我不想共享密码或有关用户的 AdminNotes。我应该创建另一个类来表示 UserProfile 摘要并从我的 ORM 实体中手动填充它吗？我应该使用任何特殊模式来填充这些对象吗？或者我可以创建仅代表数据子集的类似 ORM 对象吗？
或者我应该使用各种接口来表示我的数据类型并简单地序列化接口？
我使用 ASP.NET MVC3 托管我的 Web 服务，并使用 JSON 序列化所有内容。尝试将这些 EF ORM 对象序列化为 JSON 时会遇到复杂情况吗？
谢谢！
因此，在这种情况下，我不想共享密码或有关用户的 AdminNotes。我应该创建另一个类来表示 UserProfile 摘要并从我的 ORM 实体中手动填充它吗？
我应该使用任何特殊模式来填充这些对象吗？或者我可以创建仅代表数据子集的类似 ORM 对象吗？
是的，创建 ViewModel。您也可以考虑使用限界上下文。 您选择的方法将反映您计划使用的首选数据访问和分层技术。拥有视图，即特殊类，用于 Rest 或 Web 服务以及用于 MVC 访问是一种常用的模式。
或者我应该使用各种接口来表示我的数据类型并简单地序列化接口？
有些人确实序列化了 Data Domain 模型。其他人选择不这样做。使用代理等因素会影响此类决定。我个人不经常这样做。
我使用 ASP.NET MVC3 托管我的 Web 服务，并使用 JSON 序列化所有内容。尝试将这些 EF ORM 对象序列化为 JSON 时会遇到复杂情况吗？
是的，如果使用 EF 代理，您可能会对序列化感到头疼。如果您在您的域上创建特殊视图并使用众多映射工具之一来填充视图或从视图中检索，那么您出现问题的可能性较小，并且 UI 和服务层可以分离。
假设您有直接基于域类的服务。如果修改类以反映数据库更改会发生什么。? 很难屏蔽这种对消费者的影响。所以是的，我建议您采用 ViewModel 方法。
这类设计/架构问题会引发很长时间的讨论。考虑进行一些研究以熟悉该主题。