Где должна быть бизнес-логика (и что это такое? )реально жить и как это сделать с помощью Spring?

Я как раз читал эту статью:

http://www.tutorialized.com/view/tutorial/Spring-MVC-Application-Architecture/11986

что я нахожу отличным. Он хорошо объясняет архитектуру слоев, и я был рад, что архитектура, с которой я работаю, в значительной степени соответствует тому, что он описывает.

Но есть одна вещь, которую я, кажется, не понимаю:

Во-первых :, что именно является бизнес-логикой, а что нет? В статье он говорит (, и не он один ), что бизнес-логика должна идти в модели предметной области. Таким образом, класс Accountдолжен иметь метод activate(), который знает, как активировать Account. Насколько я понимаю, это, вероятно, потребует некоторой настойчивой работы. Но модель предметной области не должна зависеть от DAO. Только сервисный уровень должен знать о DAO.

Итак, является ли бизнес-логика тем, что доменная сущность может делать сама с собой? Подобно тому, как метод activate()устанавливает для свойства activeзначение true, а также устанавливает для свойства dateActivatedзначение new Date(), а затем задача службы сначала вызывает account.activate(), а затем — dao.saveAccount(account)? А какие внешние зависимости идут в сервис? Это то, что я делал до сих пор в основном.

public AccountServiceImpl implements AccountService
{
  private AccountDAO dao;
  private MailSender mailSender;

  public void activateAccount(Account account)
  {
     account.setActive(true);
     account.setDateActivated(new Date());
     dao.saveAccount(account);
     sendActivationEmail(account);
  }
  private void sendActivationEmail(Account account)
  {
   ...
  }
}

Это в отличие от того, что он говорит, я думаю, нет?

Чего я также не понимаю, так это примера того, как иметь объекты домена Spring wire, такие как Account. Это необходимо, если Аккаунт самостоятельно отправит свою электронную почту -.

Учитывая этот код:

import org.springframework.mail.MailSender;  
import org.springframework.mail.SimpleMailMessage;  

public class Account {  
   private String email;  
   private MailSender mailSender;  
   private boolean active = false;  

   public String getEmail() {  
      return email;  
   }  

   public void setEmail(String email) {  
      this.email = email;  
   }  

   public void setMailSender(MailSender mailSender) {  
      this.mailSender = mailSender;  
   }  

   public void activate() {  
      if (active) {  
      throw new IllegalStateException("Already active");  
      }  

      active = true;  
      sendActivationEmail();  
   }  

   private void sendActivationEmail() {  
      SimpleMailMessage msg = new SimpleMailMessage();  
      msg.setTo(email);  
      msg.setSubject("Congrats!");  
      msg.setText("You're the best.");  
      mailSender.send(msg);  
   }  
}

Если я использую Hibernate, я могу использовать DependencyInjectionInterceptorFactoryBeanдля подключения mailSender. Если бы я вместо этого использовал JDBC, я бы действительно написал громоздкий код? Кроме того, также, когда я создаю новый экземпляр для учетной записи в контроллере MVC, скажем, для заполнения его моделью ??

  BeanFactory beanFactory = new XmlBeanFactory(  
     new ClassPathResource("chapter3.xml"));  
  Account account = new Account();  
  account.setEmail("email@example.com");  
  ((AutowireCapableBeanFactory)beanFactory).applyBeanPropertyValues(  
        account, "accountPrototype");  
  account.activate(); 

Это не надежно и очень громоздко, не так ли? Мне приходилось спрашивать себя, где был создан этот объект, всякий раз, когда я вижу экземпляр Account. Плюс,если бы я пошел с этим подходом :, у меня не было бы ни одного appContext.xml, который я мог бы передать, а несколько, один для сохраняемости, один для конфигурации службы. Как бы я это сделал? Кроме того, это будет создавать совершенно новый контекст каждый раз, когда создается такой экземпляр, или я что-то упустил?

Нет ли лучшего решения для этого?

Любая помощь приветствуется.