Question

Our current application uses a smart object style for working with the database. We are looking at the feasibility of moving to PetaPoco instead. Looking over the features I notice you can add attributes to make it easier to CRUD objects. Does adding these attributes have any negative side effects that I should be aware of?

Has anyone found a reason NOT to use these decorators?

Answer 1

Directly to the use of the POCO object instance itself? None.

At least not that I would be aware of. Jon Skeet should be able to provide more info because he knows compiler inner workings through and through, so he knows exactly what happens with this metadata after it’s been compiled.

Other implications indirectly related to these

There are of course implications when accessing these declarative attributes, because they’re read using reflection which is normally a slow process.

But there’s nothing to worry here, because PetaPoco is a smart library and reads these only once then compiles & caches these things, so you only get penalized once then you get blazing performance afterwards. Because it uses compiled code.

Non-performance related implications

By putting attributes (any) on your classes/properties/methods you somehow bind your code to particular engine that will use this class, because they’re directives for this particular engine to understand your code.

In case of PetaPoco attributes this means that your class can be used with PetaPoco but not with some other DAL (ie. EF) unless you add attributes of that one as well (EF Code First uses the very same approach with attributes).

The second implication is related to back-end database. In case you rename a table, column or any other part that is provided in your PetaPoco attribute as a constant magic string, you will subsequently have to change this string as well. This just means that you have to be thorough when doing database changes…