是否有理由使用get/put方法而不是项目访问？

我发现我最近一直在实现类表面上的Mapping接口（它们本质上只是键值存储，没有更多的元数据），但在它们下面有时相当复杂。是否有理由使用get/put方法而不是项目访问？

下面是日益严重的几个例子：

它包装另一个映射转换的所有对象为字符串时设置的对象。
一个对象，它使用本地数据库作为后端来存储键值对。
向远程服务器发出HTTP请求以获取/设置数据的对象。

让我们假设所有这些例子中无缝地实现映射接口，并且有有鬼的唯一指示事情是访问项目的潜在可能需要几秒钟，一个项目可能无法在同一检索形式存储（如果有的话）。我对第一个例子非常满意，第二个例子很好，但是对于最后一个例子我感到不舒服。

问题是，是否有一行这些模型的API不应该使用项目访问，即使底层结构可能觉得它适合在表面上？

2010-07-16 Mike Boers

从严格的哲学观点来看，我不认为有一条线可以与此交叉。如果某种工具提供了所需的功能，但其API不同，则可以适应。唯一不应该这样做的情况是，如果API适应性不足以用所需的方式操纵调整后的组件。

我会毫不犹豫地将数据库调整为字典，因为这是一种处理集合的好方法，并且它已经与其他很多代码兼容。如果我发现我的特定应用程序必须调用数据库连接begin(),commit()和rollback()方法才能正常工作，则dict不会执行此操作，因为dict没有事务语义。

来源

2010-07-16 03:10:08 SingleNegationElimination

但是如果交易是可选的呢？pybsddb这样做：你可以使用dict风格的访问，但你根本无法访问事务。 – 2010-07-16 11:39:15

我的意思是我不会在我的应用程序实际上想要使用这些事务语义的情况下使用dict适配器。如果你不需要它们，或者其他典型的字典，那么继续，让它看起来像一个字典！ – SingleNegationElimination 2010-07-17 01:34:22

听起来好像您正在描述标准anydbm模块语义。正如anydbm可能引发异常anydbm.error一样，您的子类也可以根据需要提升MyDbmTimeoutError等衍生产品。无论您是将其实施为字典操作还是函数调用，调用者仍然必须与例外情况进行竞争（例如，KeyError,NameError）。

我认为在Python 2中存在任意的“绑定”哈希值，3.x对于说这是一个合理的方法是合理的理由。事实上，我一直在寻找（并在我的脑海中设计）比简单的键⇒值映射更复杂的绑定，而不需要过多的ORM SQL层。

加入：我越想越想，Pythonic绑定的字典似乎越多。一个密钥⇒值集合是一个字典。无论它是生活在核心，磁盘还是网络中，都是一个最佳抽象的实现细节。唯一的实质性差异是增加了延迟和可能的不可用性;然而，在基于虚拟内存的操作系统上，“核心”可能比RAM更具延迟性，而在多处理操作系统中，“核心”也可能无法使用。所以这些只是程度上的差异，而不是善意。

来源

2010-07-16 00:35:08 msw

是否有理由使用get/put方法而不是项目访问？

回答

相关问题