还有其他人认为实例变量在数据库支持的应用程序中存在问题吗？
我发现 C# 等语言的状态控制并没有得到很好的支持。
我的意思是，由程序员来管理内存中对象的状态。一个常见的用例是域模型中的实例变量是驻留在持久存储（即数据库）中的信息的副本。显然这违反了单点授权原则，并且“同步”必须由开发人员管理。
我设想了一个系统，其中不是实例变量，而是简单的公共访问/修改器方法，这些方法标记有将它们链接到数据库的属性，并且读取和写入由决定是否访问数据库的框架介导。这样的系统存在吗？
我是否完全没有抓住要点，或者这个想法有一定道理吗？
It occurs to me that state control in languages like C# is not well supported.
By this, I mean, it is left upto the programmer to manage the state of in-memory objects. A common use-case is that instance variables in the domain-model are copies of information residing in persistent storage (i.e. the database). Clearly this violates the single point of authority principle, and "synchronisation" has to be managed by the developer.
I envisage a system where instead of instance variables, we have simple public access/mutator methods marked with attributes that link them to the database, and where reads and writes are mediated by a framework that decides whether to hit the database. Does such a system exist?
Am I completely missing the point, or is there some truth to this idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果我正确理解你想要什么：任何带有延迟加载的 OR-Mapper 都是这样工作的。例如，我使用 Genome ，每个实体都是一个纯粹的代理，你有很大的影响力来告诉 OR -Mapper如何缓存字段。
If i understand correctly what you want: Any OR-Mapper with Lazy Loading is working this way. For example i use Genome and there every entity is a pure proxy and you have quite much influence to tell the OR-Mapper how to cache the fields.
实际上，存在数据流行的概念（由 Java 中的 prevayler 实现），其中内存中的对象是单个对象数据的权威点 (SPA)。
此外，某些对象数据库（如db4o）在对象表示和“存储”表示之间有点模糊。
另一方面，通过将 SPA 引入应用程序内部，您需要自己处理事务和/或数据持久性。在事务内存系统上已经完成了一些工作，例如 JVSTM（目前在我以前大学的信息系统使用）但它没有得到广泛使用。
另一方面，如果数据存在于数据库中，您可以在一切正常时提交数据（或使用数据库中内置的事务支持），并确保数据不会损坏或丢失。您可以利用 SPA 原则换取更好的数据可靠性和交易（以及使用单独数据存储的其他优势）
Actually there's the concept of data prevalence (as implemented by prevayler in Java) where the in-memory objects are the single point of authority (SPA) for the data.
Also, some object databases (as db4o) blur lines a bit between the object representation and the "store" representation.
On the other hand, by bringing the SPA for the data inside the application, you need to handle transactions and/or data persistence by yourself. There is some work done on transactional memory systems such as JVSTM (currently in use by the information system of my old college) but it's not in widespread use.
On the other hand, if the data lives in a database, you can just commit the data when everything is good (or use the support for transactions built in the database) and be sure that data isn't corrupted or lost. You trade in the SPA principle for better data reliability and transactions (and other advantages of using a separate data store)