Будьте в спящем режиме вопрос о размещении аннотации
Если вы просто пытаетесь увидеть, существует ли $options['categories']['all'] и есть ли в нем что-то, код можно упростить до:
$all_categories = !empty($options['categories']['all']);
Вам не нужно проверять, является ли $options['categories'] set, потому что если установлено
$options['categories']['all'], то массив, который его содержит, должен быть установлен. И троичный, который возвращает true для истинной части и false для ложной части, добавляет ненужную сложность. Выражение перед ? уже дает вам нужное логическое значение.
5 ответов
С точки зрения производительности и дизайна использование аннотаций на методов get является лучшей идеей, чем членские переменные, потому что методы set метода get называют с помощью отражения, если помещено в поле, чем метод. Также, если Вы запланируете использовать проверку, и другие функции в спящем режиме, у Вас будут все аннотации в одном месте, вместо того, чтобы рассеять их повсеместно.
Моя рекомендация идут с методами не членские переменные.
Из документации
В зависимости от того, аннотируете ли Вы поля или методы, тип доступа, используемый, в спящем режиме, будет поле или свойство. Спецификация EJB3 требует, чтобы Вы объявили аннотации на тип элемента, к которому получат доступ, т.е. метод получателя, если Вы будете использовать доступ свойства, поле при использовании доступа к полю. Смешивания аннотаций EJB3 и в полях и в методах нужно избежать. Будьте в спящем режиме предположит тип доступа от положения @Id или @EmbeddedId.
Вы получили меня на правильном пути инструментарий. Спасибо. Вот соглашение... Конечно, мой изобретенный пример не включал целую историю. Мой класс Виджета был на самом деле намного больше, чем пример, который я дал. У меня есть несколько дополнительных полей/методов get, и я был СМЕШИВАНИЕ мои аннотации. Таким образом, я аннотировал @Id на поле, но другие аннотировались на методе get.
, Таким образом, мораль истории - то, что Вы не можете смешать местоположения аннотации. Или все аннотации находятся на полях, или они находятся на методах получателя. Долговременный Java и В спящем режиме, в новинку для Аннотаций. Изучайте что-то каждый день.
, Как только я знал, что к Google, поскольку я столкнулся с этим, которое было полезно - http://chstath.blogspot.com/2007/05/field-access-vs-property-access-in-jpa.html
, Конечно, это теперь поднимает вопрос, относительно которого лучше с точек зрения дизайна и производительности.
Большая досягаемость, но у Вас есть старое *.hbm.xml файл, плавающий вокруг?
, Возможно, это могло бы брать неправильную установку для default-access и использование property вместо field?
Делает это работает, если Вы делаете следующее:
@Entity
@Table(name="widget")
public class Widget {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private Integer id;
public Integer getId() { return this.id; }
public Integer setId(Integer Id) { this.id = id;}
}
Это очень хорошая ссылка, которая может помочь вам понять типы доступа и соответствующие передовые методы!
Недостаточное понимание @AccessType в Hibernate