Question

Assuming my application did not warrant a full blown DDD setup, would Repositories still be useful? I like the way they shield from implementation details (such as use of Entity Framework) underneath. However Repositories tend to be tied to Aggregate Roots (the concept is still a holy grail to me) by definition.

I suppose the question could also be put as such: if I have a typical 3-tier application, with a business layer facade consisting of “logical grouping” classes based on functionality (rather than aggregate roots as in DDD) such as TradingManager and ContactsManager, would it make sense to also create “logical grouping” repositories. Or perhaps a Data Access Object, which I believe is like a Repository without the aggregate root requirement. Of course I will still have a Model (EF POCOs) that will be passed up and down between the layers.

Also, is what I just described would be considered as a Transaction Script approach? It’s certainly not DDD, and not Active Record. I’m not even sure if Active Record exists with EF4 like it does with Nhibernate.

I am trying to understand how others structure n-layered applications when they do not follow DDD.

Answer 1

As you’ve hinted, it sounds like your going more for a DAO. I think DAOs are very useful in non-DDD projects where you want to abstract the data layer technology completely away.

As far as transaction script goes, it is orthogonal to your data layer design. Transaction script implies that each business operation is grouped into a procedural call. Example: the transaction script pattern is often used in WCF service calls on the server side, with each service method following the transaction script pattern. Think of it this way: with transaction script, the actual business logic is not in objects, rather it’s written right in the transaction script procedure call. Common business logic may be shared between transaction scripts, but it’s usually done through static methods, helpers, etc… and not through “pure” OO.

Here’s a bit of pseudo-code

// traditional transaction script
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       if(db.UserExists(userName))
       {
          if(EmailHelper.ValidateEmailFormat(newEmail))
          {
             db.UpdateEmail(userName, newEmail);
          }
       } 
    }
}

// transaction script with anemic domain objects
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       var userDAO = new UserDAO();
       var emailDAO = new EmailDAO();

       var existingUser = userDAO.GetUserByName(userName);       

       if(existingUser != null)
       {
          if(EmailHelper.ValidateEmailFormat(newEmail))
          {
             emailDAO.UpdateEmail(existingUser, newEmail);
          }
       } 
    }
}  

// More of an OO / DDDish approach
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       var userRepository = new Repository<User>();

       var userToUpdate = userRepository.Where(x => x.UserName = userName).FirstOrDefault();

       if(userToUpdate != null)
       {
           userToUpdate.Email = newEmail;

           if (user.IsValid())
           {
               userRepository.Update(userToUpdate);
           } 
       }
    }
}

Obviously the first example isn’t OO at all. The 2nd example is more object-based than OO as all of the business logic happens in the MailService call. The third example is traditional OO. Only the control flow occurs in the service call; all of the business logic is handled in the User.IsValid() method.

It all boils down to where you put the business logic.