标签: business-objects

我知道DTO是一个数据传输对象,BO是一个业务对象.但是,它究竟意味着什么？我什么时候应该选择其中一个？从我的理解DTO仅用于传输数据而没有业务逻辑.这是否意味着DTO没有任何方法属性(getter和setter)？但是,它仍然具有BO的属性.有人可以解释一下吗？谢谢.

在我工作的地方,我们已经多次在这个问题上来回走动,正在寻找一个健全性检查.这是一个问题:Business Objects应该是数据容器(更像是DTO)还是应该包含可以对该对象执行某些功能的逻辑.

示例 - 获取客户对象,它可能包含一些常见属性(Name,Id等),客户对象是否还包含函数(Save,Calc等)？

一行推理说,将对象与功能(单一责任主体)分开,并将功能放在业务逻辑层或对象中.

另一条推理说,不,如果我有一个客户对象,我只想打电话给Customer.Save并完成它.如果我正在使用该对象,为什么我需要知道如何保存客户？

我们的最后两个项目已经将对象与功能分开,但是在新项目中再次提出了争论.哪个更有意义？

编辑

这些结果与我们的辩论非常相似.对一方或另一方的一票完全改变了方向.有没有人想加2美分？

编辑

尽管答案抽样很小,但似乎大多数人认为业务对象中的功能是可接受的,只要它很简单,但持久性最好放在单独的类/层中.我们试一试.感谢大家的投入......

我有一个水晶报告,并且详细信息部分中有一个字段,当前显示每行.将此字段设置为在第一行只显示一次的方法是什么？

我以前从未使用过实体框架,我想尝试一些实现它的个人项目来让我的脚湿透.

我看到实体可以暴露给表示层.但我不希望暴露某些字段,修改日期和创建日期等字段以及各种其他数据库字段.

我怎么能实现业务对象,只是暴露我需要的属性,但仍然保持对象可序列化？

这对LinqToSql有什么优势？

有人请解释一下这个区别吗？这些产品是否相同,如果不是,它们各自用于什么？

Martin Fowler建议使用服务层作为域模型和"数据加载器"之间的边界.但是,Rockford Lhotka建议在业务对象本身中构建验证,这正是CSLA.NET所做的.

将此抽象到服务层的好处显然是您的服务层可以跨多个业务对象协调活动/操作.但是,使用服务层而不是直接使用业务对象进行业务逻辑和验证有哪些其他优点和缺点？

所以我有一个DAO,DTO和BO.以下代码是结果:

// Instantiate a new user repository.
UserRepository rep = new UserRepository();

// Retrieve user by ID (returns DTO) and convert to business object.
User user = rep.GetById(32).ToBusiness<User>();

// Perform business logic.
user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

// Convert business object back to a DTO to save to the database.
rep.Save(user.ToDataTransfer<Data.DTO.User>());

所以我试图分开关注点,但我想摆脱这段代码中的"转换"."转换"实际上位于业务逻辑层(DTO层不知道业务逻辑层)作为扩展对象.DTO本身显然只存储数据,并且没有任何业务逻辑.UserRepository调用DAO,在GetById结束时使用AutoMapper从DAO映射到DTO."转换"(ToBusiness和ToDataTransfer)完全按照他们的说法行事.

我的一位同事认为我可能需要有一个商业资源库,但认为它可能有点笨重.有什么想法吗？

我得到了创建业务对象或实体来表示类似Person的概念.然后我可以使用DTO序列化Person并将其发送给客户端.如果客户端更改了对象,它可以在那里有一个IsDirty标志,所以当它被发送回服务器时,我知道要更新它.

但是如果我有一个Order对象呢？这有主页头信息,客户,供应商,所需日期等.然后它有OrderItems,它是一个List <OrderItem>,是要订购的项目.我希望能够在我的UI上使用此业务对象.所以我有一些文本框连接到位置,供应商,所需日期等,并且网格连接到OrderItems.由于OrderItems是一个List,我可以轻松地添加和删除记录.但是我该如何跟踪这个,特别是删除的项目.我不希望删除的项目在我的网格中可见,如果我使用foreach,我不应该迭代它们,因为它们已被删除.但是我仍然需要跟踪删除的事实.如何跟踪更改.我想我需要使用一个单位的工作？但随后代码似乎变得相当复杂.那么我想知道为什么不简单地使用DataTables并免费获得更改跟踪？但后来我读到了业务对象是如何实现的.

我在简单的Person示例中找到了各种示例,bnut不是像Orders这样的标题详细示例.

BTW使用C#3.5.

我看到这个术语常用,就好像在讨论面向OO语言的MVC时两者之间有一个具体的区别.从我从上下文中得到的是,商业模型执行一个动作来改变数据模型.这是表达差异的正确方法吗？

我想让我感到困惑的是,大多数模型的例子都混合了这两种角色,表面上看起来很自然.通常,更改对象状态的方法位于这些对象本身内部.我想我无法想出一个如何在现实世界中运作的例子.更改对象的方法在该对象内部似乎更自然.任何人都可以更清楚地解释一下吗？

我刚读这篇文章:

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线域对象的示例Account.如果账户自己发送电子邮件,则需要哪些.

鉴于此代码:

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

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