我是 EF 和数据库设计的新手。我一直在研究如何使用 Repository Pattern 和 Unit of Work，并且看到了很多使用 LINQ 进行的查询。
但我有一个问题。如果将来我们更改数据库的架构，则存储库层必然会发生变化，因为实体本身也会发生变化。换句话说，存储库层与数据库结构紧密耦合。
但是，如果我们使用数据库本身的存储过程封装大部分可能的事务，然后使用 EF 导入它们，那么数据库设计中的更改不会对存储库层产生太大影响。换句话说，层将是这样的：
DATABASE TABLES <---> STORED PROCEDURES <---> EF <---> REPOSITORY <---> APPLICATION LOGIC
为什么我们不遵循这种模式，或者我忽略了任何陷阱？这不是将应用程序与数据库松散地耦合在一起吗？
我认为使用 LINQ 还会将架构与应用程序绑定，这是我关心的问题。如果将来我想进一步规范我的数据库，那就意味着重写整个 LINQ 查询。这是我更喜欢视图而不是显示原始表格的另一个原因。这就像在类中使用属性而不是字段。它增加了一层封装。
免责声明：我是数据库领域的初学者。
我正在尝试在 PostgresQL 中设计一个数据库，它将记录物品的销售和购买。我打算使用这个数据库作为使用 MVVM 方法的 EF 和 WPF 的模型。
这是设计的问题。
这是我的模式的简化描述。
我有一个 Clients 表、一个 ItemDetails 表和一个 RateChart 表，等等。
客户表记录每个客户的详细信息，包括他们的地址。
ItemDetails 表记录了我们向客户销售的每件商品的详细信息，包括商品的简短描述。我们会不时更新说明。
RateChart 表对每个客户的项目具有不同的费率。
现在，我还必须保存每笔销售的详细信息。所以，我有一个 Invoice 表和 InvoiceItems 表。
Invoice表保存发票号（主键）、日期、订单总金额和客户名（外键，指client表中的客户名）。
另一方面，InvoiceItems 表记录了售出的商品、每件商品的售出数量以及售出率。
现在，问题来了。
InvoiceItems 列表中出售的项目是对 ItemDetails 表的引用，其中保存了所有项目的详细信息。现在，项目的详细信息会不时更改。例如，物品的描述发生了变化。因此，每当我更改这些项目详细信息时，这些更改都会向下级联到此 InvoiceItems 表，并且会使较早的发票记录出错，因为那不是产品销售时的描述。同样的问题在于销售表中的客户字段。每当我更改 client 表中任何记录的属性时，更改都会向下级联到 sale 表。
这是用于说明的架构。
现在，我想到的解决方案非常不优雅。我考虑过将每次销售的客户详细信息保存在发票表中，并将项目详细信息保存在 InvoiceItems 中。当然，那将是大量的重复数据。
另一种解决方案可能是保留项目和客户的失效详细信息，这意味着我的 ItemsDetails 和客户表中的记录不再有效。当然，我可以添加一个布尔 IsValid 列，但话又说回来，解决方案似乎并不简洁。
任何帮助将不胜感激。