AOP Dirty Tracking

Question

В прошлом я использовал несколько разных методов для грязной проверки моих сущностей. Я занимался идеей использования АОП для достижения этой цели в новом проекте. Это потребовало бы, чтобы я добавил атрибут в каждое свойство в моих классах, где я хочу вызывать логику грязного флага, когда свойство установлено. Если мне нужно добавить дополнительную строку кода к каждому свойству для атрибута, какая польза от простого вызова метода SetDirty () в установщиках. Я предполагаю, что спрашиваю, в чем преимущество, если таковое имеется, использования подхода АОП?

Answer 1

Я бы сказал, что не только нет никакого преимущества в этом случае: есть немного недостатка. Вы используете одинаковое количество строк кода независимо от того, вызываете ли вы dirty() или используете AOP, но просто вызов dirty() является более простым и понятным с точки зрения намерений.

АОП, честно говоря, я немного перепродан, я думаю. Это добавляет еще один уровень косвенности, с точки зрения чтения кода, который часто не окупается.

Ключевым моментом, о котором следует подумать, является то, поможет ли следующий парень, читающий это (возможно, через несколько месяцев вы), быстрее и яснее понять, что я пытаюсь сделать. Если вам сложно понять, что лучше в менее простом подходе, вам, вероятно, не стоит его использовать. (И я говорю это как программист на Haskell, что означает, что я далек от того, чтобы противостоять непростым подходам к себе.)

Answer 2

Почему вы хотите, чтобы грязная проверка была ответственностью юридических лиц? Вы можете управлять этим где-то еще. Шаблон называется Единица работы

Answer 3

Некоторые реализации AOP, в частности PostSharp, позволяют применять атрибут на уровне сборки с подстановочными знаками в отношении классов, к которым он применяется.

Answer 4

Использование АОП для сквозных задач. Это означает, что вы хотите иметь такие функции, как ведение журнала, безопасность и т. Д., Но бизнес-логика действительно не относится к вашему классу. Это может быть связано с логикой Dirty flag, так как объект Domain не должен заботиться о том, чтобы он был изменен. Это зависит от вашей DirtyLogicUtility или от того, что она когда-либо назвала.

Например, вы хотите регистрировать каждый раз, когда метод вызывается для каждого, вы можете поместить это в каждую функцию, но позже вы захотите иметь логику, чтобы она регистрировалась при каждом другом вызове.

АОП держит ваши классы в чистоте, делая то, что они должны делать, оставляя другие части в покое.

Answer 5

Я не вижу никакой пользы, если вам нужно украсить свои сущности атрибутом. Особенно, если все, что вы делаете, - это вызов одного метода. Если бы логика была более сложной, я мог бы привести аргумент в пользу использования АОП.

Если, скажем, каждый раз, когда вы изменяете свойство, которое хотите отследить это изменение как версию, это может быть более сложное поведение, которое можно внедрить, тогда извлечение этого абстракции из свойства может быть полезным. В тот же момент вы, вероятно, захотите, чтобы версия изменила сразу несколько свойств, поэтому я возвращаюсь к тому, что значение не слишком велико.

Answer 6

Преимущество состоит в том, что если вы решите изменить реализацию вызова логики грязного флага, вам нужно будет сделать только одно изменение (в теле метода AOP), а не N изменений (заменяя все ваши SetDirty звонки с чем-то еще).