WCF 数据服务/代理键
我想构建一个 WCF 数据服务,用于数据库后端的 CRUD 操作。为了识别数据库中对象的相关记录,我必须知道它的主键。我在数据库模式中使用代理键。
将代理键传递给调用者,以便在后续调用中可以识别数据库中的记录是一个好习惯吗? (调用者检索对象,调用者修改对象,调用者调用 WCF 更新方法)我知道代理键通常不应在数据库外部使用。如果这不是一个好主意,我还有什么其他选择?
非常感谢任何建议。
I want to build a WCF data service which should be used for CRUD operations on a database backend. In order to identify the related record of the object in the database I have to know it's primary key. I use surrogate keys in my database schema.
Is it a good practice to pass the surrogate keys to the caller, so that it is possible to identify the records in the database in subsequent calls? (Caller retrieves object, caller modifies object, caller calls WCF update method) I know that surrogate keys should normally not be used outside the database. If that is not a good idea, what other options do I have?
Any advice is greatly apreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,您的解决方案完全足够了。这是将 CLR 对象映射到持久实体的最简单方法。此外,您的服务的消费者可能会发现这个独特的标识符在编程 UI 时非常有用,用于日志记录等目的。
我会毫不犹豫地采用这种方式。
Yes, your solution is totally adequate. It's the simplest way to map CLR objects to persistent entities. Moreover, your services' consumers may find this unqiue identifier useful when programming UI, for logging purposes etc.
I'd go this way without hesitation.
我认为这完全取决于您所讨论的数据类型。如果您谈论的是纯资源驱动的数据,则暴露代理键没有问题。但是,如果这是业务数据,您应该只公开业务密钥。它允许不相交的系统以通用的方式进行通信。
I think this all depends on what type of data you are talking about. If you are talking about pure resource driven data, there are no issues with exposing surrogate keys. However, if this is business data you should only expose business keys. It allows disjoint systems to talk in a generic way.