2013-03-14 120 views
3

我正在用DTO构建我的第一个应用程序 - 我目前有一个DTO用于获取特定对象的数据,另一个DTO用于更新(PUTting)数据 - 因为只有几个字段可以从任何客户端更新,我决定为PUTTING创建一个专用的DTO,以避免通过线路发送不必要的数据/字段。在可维护性方面,这是一种好的做法吗?或者这是否是否定的?DTO模式的策略 - 每个实体或只有一个DTO?

回答

1

我对使用相同类型的多个操作没有问题。也许你有多个GET类似的目的返回类似的数据。没有理由在这种情况下不能重复使用相同的类型。

但是,您已经确定您的GET和PUT操作需要不同的数据。所以他们不仅操作不同,而且需要不同的数据。

+----------------+-------------------+--------------------------+ 
| Similar Data | Similar Purpose | Try to Reuse    | 
| Similar Data | Different Purpose | Consider; is it logical? | 
| Different Data | Similar Purpose | New Type     | 
| Different Data | Different Purpose | New Type     | 
+----------------+-------------------+--------------------------+ 

有创造一个新的DTO,以满足特定的需求,如其他好处:(!哪怕就是你)

  • 没有混淆开发商
  • 没有打开一个安全漏洞因此不打算字段中使用的填充

为了更方便:

  • 接口可用于帮助强制类型之间的通用字段。
  • ASP.Net Web API(不确定是否使用您的问题)对dynamic inputs有强大的支持。这可以消除对DTO的需求(尽管以编译时类型检查较少为代价)。
+0

带源代码的任何完整示例应用程序使用图层中的DTO,MessageContracts和Mappers? – Kiquenet 2013-10-16 13:24:35

+0

@Kiquenet - 对不起,我不知道一个示例应用程序显示你正在请求。 – 2013-10-16 18:48:49

0

这是一个选择的问题。我有使用orm映射器来减少代码的习惯。我发现,花时间预先定义保存并开始使用一个dto类可以实现更好的可伸缩性和可维护性,即使它意味着所有字段都会更新。有边缘情况。如果表使用大块blob类型数据的字段,那么也许你应该以某种方式将这些更新子类化。这是一个意见问题。

-2

它不是否定的,但使用相同的DTO for CRUD将使其在长期运行中更易于维护。稍后,如果添加并删除新字段,则可能必须在所有图层中更改代码。你永远不知道你的客户何时改变主意来编辑更多或更少的数据。

+0

-1在内部层之间*可能是可以接受的,但是用于HTTP操作的相同DTO不太可能是适用于CRUD的相同类型。无论如何,这不是被问到的问题。 – 2013-03-14 02:37:26

+0

-1为你的-1。有一个潜在的假设,即通过服务层将对象从数据库层转移到表示层。我同意,这取决于它的架构如何,但不是决定必须由知道它的分层的人最终采取。不是你,也不是我。 – Atul 2013-03-14 02:59:10

0

我确实为每个实体使用多个DTO。然而,很多时候我甚至没有为视图预定义的DTO,我只是创建一个匿名类实例,它是使用Linq的实体的投影并将其绑定到GUI。

E.g.显示用户

var users = ... // fetch from DB 
ViewData["users"] = users.Select(u => new { Id = u.Id, Name = u.First + " " + u.Last}); 

显示比分板的名单:

var users = ... // fetch from DB 
ViewData["users"] = users.Select(u => new { Id = u.Id, Name = u.Last, Score = u.Score}); 

这样可以节省我从创建2层不同的DTO。一个潜在的缺点是该视图不是强类型的,所以取决于ASP.NET MVC的版本,我需要将视图模型声明为dynamic或使用一些ExpandoObject技巧,但它很好地隐藏。

但是,我总是创建DTO来修改状态并将它们视为命令。对于实体上的不同操作,我通常具有不同的DTO。 ChangeUserAddressDTO,ChangeUserLevelDTO