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