Наше текущее приложение использует стиль смарт-объектов для работы с базой данных. Вместо этого мы рассматриваем возможность перехода на PetaPoco. Просматривая функции, я заметил, что вы можете добавлять атрибуты, чтобы упростить объекты CRUD. Есть ли у добавления этих атрибутов какие-либо негативные побочные эффекты, о которых мне следует знать?
Кто-нибудь нашел причину НЕ использовать эти декораторы?
Непосредственно к использованию самого экземпляра объекта POCO? Нет.
По крайней мере, я бы не знал. Джон Скит должен быть в состоянии предоставить больше информации, потому что он знает внутреннюю работу компилятора насквозь, поэтому он точно знает, что происходит с этими метаданными после их компиляции.
Конечно, при доступе к этим декларативным атрибутам есть определенные последствия, потому что они считываются с использованием отражения, которое обычно является медленным процессом.
Но здесь не о чем беспокоиться, потому что PetaPoco — это умная библиотека, которая читает их только один раз, а затем компилирует и кэширует эти вещи, поэтому вы получаете штраф только один раз, а затем получаете молниеносную производительность. Потому что он использует скомпилированный код.
Помещая атрибуты (любые) в свои классы/свойства/методы, вы каким-то образом привязываете свой код к конкретному движку, который будет использовать этот класс, потому что они являются директивами для этого конкретного движка, чтобы понять ваш код.
В случае с атрибутами PetaPoco это означает, что ваш класс можно использовать с PetaPoco, но не с каким-либо другим DAL (например, EF), если только вы не добавите атрибуты этого класса (EF Code First использует тот же подход с атрибутами).
Второе последствие связано с серверной базой данных. Если вы переименуете таблицу, столбец или любую другую часть, указанную в вашем атрибуте PetaPoco, в виде постоянной волшебной строки, впоследствии вам придется изменить и эту строку. Это просто означает, что вы должны быть тщательными при внесении изменений в базу данных...
Одним из недостатков является то, что он разрушает разделение между уровнем «домен» и уровнем «данных», поскольку он вводит файл PetaPoco (который содержит логику данных) для классов домена, которые на самом деле не должны иметь никаких знаний или зависимости от уровня данных.
Если вы делаете однопроектное приложение MVC или что-то в этом роде, то можно просто использовать каталог Models для обоих, но для нетривиальных и разделенных приложений вам придется иметь два файла PetaPoco или поиграться с абстрагирующими частями файл, чтобы аннотировать свои модели, не заставляя их «слишком много знать» о базовых данных, или же вы указываете имя таблицы и/или первичного ключа повсюду.
