设计模式 – 在ViewModels中使用服务层类.设计缺陷?

设计模式 – 在ViewModels中使用服务层类.设计缺陷?,第1张

概述我想知道我的解决方案是否存在设计缺陷.这就是我所拥有的: >实体=>纯poco. refs:none. >数据=>数据访问. refs:实体. >服务=>商业逻辑. refs:实体和数据 >经理类. > ViewModels. > WebApp => UI.参考:实体和服务 WebApp ASP.NET MVC项目作为UI,Entities项目没有参考,用于保存纯POCO.访问数据库和Servic 我想知道我的解决方案是否存在设计缺陷.这就是我所拥有的:

>实体=>纯poco. refs:none.
>数据=>数据访问. refs:实体.
>服务=>商业逻辑. refs:实体和数据

>经理类.
> viewmodels.

> WebApp => UI.参考:实体和服务

WebApp ASP.NET MVC项目作为UI,EntitIEs项目没有参考,用于保存纯POCO.访问数据库和Service for Business Logic的数据(我的Manager类所在的位置).

基本上,我为每个实体定义了一个Manager类.例如,我有一个与收件人实体列表有关的Message实体.我有一个MessageManager和RecipIEntManager类,负责使用数据层和逻辑结果的CRUD *** 作(例如public List< Message> GetAllMessagesWithPermissionForUser(User user,Permission permission))

对于我的MVC项目,我在Service层中定义了一些viewmodel类来为我的视图生成特定的视频模型.由于视图模型使用的是Manager类,因此我在我的服务类中定义了它们.例如,我有一个MessageOperationVM viewmodel,它具有PermittedBoxesToSend属性.此属性使用我的BoxManager类获取指定消息允许的所有框:

// Initialized by Catsle Windsor.public BoxManager BoxManager {get; set;}public List<Box> PermittedBoxesToSend {    if(this._premittedBoxesToSend != null)    {        this._permittedBoxesToSend = BoxManager.GetPermittedBoxesToSend(this.Message);    }}

>我不确定在viewmodels中使用管理器类是否是一个好的设计.虽然我已经将它们定义为构造函数/属性setter以填充DI.我应该在控制器中填充我的viewmodels属性而不是定义属性并在我的viewmodels中删除管理器类吗?

public ActionResult ShowNewMessageDialog(){     var messageVM = new MessageOperationVM() { new Message() };    messageVM = this.BoxManager.GetPermittedBoxesToSend();}

>为每个实体使用经理类似乎使维护变得困难. (尽管它们都来自BaseManager类,它共享它们共有的 *** 作)
>在上述设计中是否有任何值得一提的重新考虑?

谢谢.

更新:
基于eulerfx的回答:
我的回答是:要构建一个viewmodel,我必须调用一些服务层的方法.所以我不能仅仅根据我的poco实体构建我的viewmodel.你是否建议我也应该在控制器中构建这些部件? :

public ActionResult ShowNewMessageDialog(){    var message = this.messageRepository.GetMessage();    var messageVM = new Messageviewmodel(message);    messageVM.CustomProperty = this.messageManager.CallSomeMethod(message);    return VIEw(messageVM);}
解决方法 我会考虑视图模型的引用来为设计缺陷提供服务.视图模型应该是扁平的,简单的DTO用于与视图绑定.它们不应该是DI容器图的一部分,因为这会使事情复杂化并使代码的推理变得更加困难.您使用的术语的可接受定义如下.

> Entites是您描述的实体.它们是简单的POCO类.
>您所谓的“数据”是repository pattern.存储库提供对底层数据库中实体的访问和持久性.
>服务是一个重载术语,但它们通常用于封装域,将其作为API暴露给其他应用程序层.服务可以引用存储库.我在DDD here的上下文中写了一篇关于这些类型服务的博客文章,它们被称为应用程序服务.
>视图模型是您调用它的表示层或WebUI的一部分.因此,它们由MVC控制器构造并传递给视图.控制器使用从应用程序服务获得的数据或直接从存储库构建视图模型.视图模型可以包含一个构造函数,该构造函数接受服务或存储库返回的实体.

代码看起来像这样:

/// Domain model class that lives in domain/business layer projectpublic class Message{  // propertIEs and behavior go here}// VIEw model class that lives in the ASP.NET projectpublic class Messageviewmodel{  public Messageviewmodel() { }  public Messageviewmodel(Message message)  {    // construct the vIEw model based on the provIDed entity  }  // propertIEs specific to the vIEw go here} // ASP.NET MVC controller.public class MessagesController : Controller{ // this repository should be injected by DI container. Readonly IMessageRepository messageRepository; public ActionResult ShowNewMessageDialog() {   var message = this.messageRepository.GetMessage();   return VIEw(new Messageviewmodel(message)); }}
总结

以上是内存溢出为你收集整理的设计模式 – 在ViewModels中使用服务层类.设计缺陷?全部内容,希望文章能够帮你解决设计模式 – 在ViewModels中使用服务层类.设计缺陷?所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/1085704.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-27
下一篇 2022-05-27

发表评论

登录后才能评论

评论列表(0条)

保存