应用程序设计 - 数据库表和接口

Question

我有一个数据库，其中包含系统中每个实体的表格。例如PersonTable包含PersonId，Name，HomeStateId列。还有一个表格用于“参考数据”（即州，国家，所有货币等）数据，这些数据将用于填充下拉列表框。此引用表也将被使用，以便PersonTable的HomeStateId将成为引用表的外键。

在C＃应用程序中，我们有为实体定义的接口和类。 例如PersonImplementationClass：IPersonInterface。为每个实体设置接口的原因是因为实际的实体类将根据可能发生变化的第三方产品以不同方式存储数据。

问题是，接口是否具有Name，HomeStateId和HomeStateName的属性（将从引用表中检索）。或者接口是否应该公开数据库的结构，即没有HomeStateId，只有Name，HomeStateName？

Answer 1

在考虑房产名称时，我会说你走在正确的轨道上！

为您的课程建模，就像在现实世界中一样。

一般忘记StateID和外键的数据库模式和命名约定。一个人有一个城市，而不是cityID。

您的数据层将在运行时映射和填充这些对象的属性。您应该可以自由地在代码中表达您的意图和“真实世界”对象的表示，而不是坚持您的数据库实现。

Answer 2

无论哪种方式都可以接受，但它们都有其优点和缺点。

第一种方式（实体具有ID）与 ActiveRecord 模式类似，其中您的实体是数据库结构上的瘦包装。这通常是一种灵活，快速的结构化数据层的方法，因为您的实体可以自由地直接使用数据库来完成域操作。缺点是当数据模型发生变化时，您的应用可能需要维护。

第二种方式（实体更多地反映了现实世界的结构）更像是一个更重的 ORM，如Entity Framework或Hibernate 。在这种类型的数据访问层中，您的实体管理框架将负责自动地将实体映射到数据库中。这样可以更清晰地将应用程序与数据分开，但可以处理更多的管道。

这是一个很大的选择，不应掉以轻心。这实际上取决于您的项目要求和规模，谁将消费它。

Answer 3

将设计分开可能会有所帮助。

对于每个实体，使用两个类：

• 处理实体上的数据库操作（将放置ID）的人
• 一个简单的数据对象（你将拥有实际意味着什么的标准字段）

正如@womp所提到的，如果你的实体持久性只发生在数据库中，那么强烈会考虑使用ORM，这样你就不会自己动手了。