Пример ниже является полностью искусственным, и его единственная цель состоит в том, чтобы донести мою точку зрения.
Предположим, у меня есть таблица SQL:
CREATE TABLE rectangles (
width int,
height int
);
Класс домена:
public class Rectangle {
private int width;
private int height;
/* My business logic */
public int area() {
return width * height;
}
}
Теперь предположим, что у меня есть требование показать пользователю общую площадь всех прямоугольников в базе данных. Я могу сделать это, выбирая все строки таблицы, превращая их в объекты и перебирая их. Но это выглядит просто глупо, потому что в моей таблице много и много прямоугольников.
Итак, я делаю это:
SELECT sum(r.width * r.height)
FROM rectangles r
Это легко, быстро и использует сильные стороны базы данных. Тем не менее, он вводит дублированную логику, потому что у меня есть те же вычисления в моем классе домена.
Конечно, для этого примера дублирование логики вовсе не фатально. Тем не менее, я сталкиваюсь с той же проблемой с другими моими классами домена, которые являются более сложными.
источник
Ответы:
Как указал lxrec, он будет варьироваться от кодовой базы к кодовой базе. Некоторые приложения позволяют вам помещать такую бизнес-логику в функции SQL и / или запросы и позволяют запускать их в любое время, когда вам нужно показать эти значения пользователю.
Иногда это может показаться глупым, но лучше кодировать для правильности, чем для производительности в качестве основной цели.
В вашем примере, если вы показываете значение области для пользователя в веб-форме, вам необходимо:
Это глупо для простых вещей, таких как пример, но может потребоваться более сложные вещи, такие как расчет IRR инвестиций клиента в банковскую систему.
Код на правильность . Если ваше программное обеспечение работает правильно, но медленно, у вас будет шанс оптимизировать, где вам нужно (после профилирования). Если это означает сохранение части бизнес-логики в базе данных, пусть будет так. Вот почему у нас есть методы рефакторинга.
Если он становится медленным или не отвечает, то вам может потребоваться выполнить некоторые оптимизации, например, нарушить принцип DRY, что не является грехом, если вы окружаете себя надлежащим модульным тестированием и тестированием согласованности.
источник
Вы говорите, что пример является искусственным, поэтому я не знаю, подходит ли то, что я здесь говорю, к вашей реальной ситуации, но мой ответ таков: используйте слой ORM (объектно-реляционное отображение) для определения структуры и запросов / манипулирования ваша база данных. Таким образом, у вас нет дублирующейся логики, так как все будет определено в моделях.
Например, используя инфраструктуру Django (python), вы определяете класс вашего прямоугольного домена как следующую модель :
Чтобы рассчитать общую площадь (без какой-либо фильтрации), вы должны определить:
Как уже упоминали другие, вы должны сначала написать код для правильности, и оптимизировать только тогда, когда вы действительно попали в узкое место. Итак, если позднее вы решите, что вам абсолютно необходимо оптимизировать, вы можете перейти к определению необработанного запроса, такого как:
источник
Я написал глупый пример, чтобы объяснить идею:
Итак, если у вас есть логика:
Вы можете повторно использовать его в классах домена:
Или в вашем уровне sql-поколения:
И, конечно, вы можете легко это изменить. Попробуй это:
источник
Как сказал @Machado, самый простой способ сделать это - это избежать его и выполнить всю вашу обработку в основной Java. Тем не менее, все еще возможно иметь кодовую базу с подобным кодом, не повторяя себя, генерируя код для обеих кодовых баз.
Например, использование cog enable для генерации трех фрагментов из общего определения
фрагмент 1:
фрагмент 2:
фрагмент 3:
из одного справочного файла
источник