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.
我认为这归结为单一责任原则。如果您的 DAO 所做的只是检索实体（嗯，执行 CRUD，而不是 DbContext），而没有其他任何事情......那么是的，使用一个。如果您开始发现不同实体有自定义逻辑，那么您将需要考虑诸如存储库之类的东西。
As always... "it depends". :D Sorry...
I think that it comes down to single responsibility principle. If all your DAO is doing is retrieving the entities (well, doing CRUD, rather, a la a DbContext), and nothing else... then yeah, roll with one. If you start finding that you have custom logic for different entities, then you'll want to consider something like a repository.
发布评论
评论（2）
正如您所暗示的，听起来您更倾向于 DAO。我认为 DAO 在您想要完全抽象数据层技术的非 DDD 项目中非常有用。
就事务脚本而言，它与您的数据层设计正交。事务脚本意味着每个业务操作都被分组为一个过程调用。示例：事务脚本模式经常用于服务器端的WCF服务调用，每个服务方法都遵循事务脚本模式。这样想：对于事务脚本，实际的业务逻辑不在对象中，而是直接写在事务脚本过程调用中。常见的业务逻辑可以在事务脚本之间共享，但通常是通过静态方法、助手等来完成的......而不是通过“纯粹的”OO。
这是一些伪代码
显然第一个例子根本不是面向对象的。第二个示例比 OO 更加基于对象，因为所有业务逻辑都发生在 MailService 调用中。第三个例子是传统的面向对象。仅控制流发生在服务调用中；所有业务逻辑都在 User.IsValid() 方法中处理。
这一切都归结为您将业务逻辑放在哪里。
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
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.
一如既往......“这取决于”。 ：D 抱歉...
我认为这归结为单一责任原则。如果您的 DAO 所做的只是检索实体（嗯，执行 CRUD，而不是 DbContext），而没有其他任何事情......那么是的，使用一个。如果您开始发现不同实体有自定义逻辑，那么您将需要考虑诸如存储库之类的东西。
As always... "it depends". :D Sorry...
I think that it comes down to single responsibility principle. If all your DAO is doing is retrieving the entities (well, doing CRUD, rather, a la a DbContext), and nothing else... then yeah, roll with one. If you start finding that you have custom logic for different entities, then you'll want to consider something like a repository.