我们当前的应用程序使用智能对象样式来处理数据库。我们正在研究改用 PetaPoco 的可行性。查看我注意到的功能，您可以添加属性以使 CRUD 对象更容易。添加这些属性是否有任何我应该注意的负面影响？
有没有人找到不使用这些装饰器的理由？
问问题
534 次
2 回答
2
一个缺点是它打破了“域”层和“数据”层之间的分离，因为它将 PetaPoco 文件（其中包含数据逻辑）引入了实际上不应该对数据层有任何知识或依赖性的域类。
如果你正在做一个单一项目的 MVC 应用程序或其他东西，那么两者都使用 Models 目录是可以的，但对于非平凡和分离的应用程序，你必须有两个 PetaPoco 文件或玩弄抽象的部分文件以便注释您的模型而不会让它们“了解太多”基础数据，或者让您在整个地方指定表和/或主键名称。
于 2012-05-22T19:33:53.657 回答
2
直接使用POCO对象实例本身？没有任何。
至少我不会意识到。Jon Skeet 应该能够提供更多信息，因为他完全了解编译器的内部工作原理，因此他确切地知道此元数据在编译后会发生什么。
与这些间接相关的其他影响
访问这些声明性属性时当然会有影响，因为它们是使用反射读取的，这通常是一个缓慢的过程。
但是这里没有什么好担心的，因为 PetaPoco 是一个智能库，并且只读取一次然后编译和缓存这些东西，所以你只会受到一次惩罚，然后你就会获得惊人的性能。因为它使用编译后的代码。
与绩效无关的影响
通过将属性（任何）放在您的类/属性/方法上，您以某种方式将您的代码绑定到将使用此类的特定引擎，因为它们是该特定引擎理解您的代码的指令。
对于 PetaPoco 属性，这意味着您的类可以与 PetaPoco 一起使用，但不能与其他一些 DAL（即 EF）一起使用，除非您也添加该类的属性（EF Code First 使用与属性完全相同的方法）。
第二个含义与后端数据库有关。如果您将 PetaPoco 属性中提供的表、列或任何其他部分重命名为常量魔术字符串，您随后也必须更改此字符串。这只是意味着您在进行数据库更改时必须彻底......
于 2012-04-12T06:07:42.017 回答