我正在使用ASP.NET MVC DefaultModelBinder
将请求绑定到模型类,但仅使用其两个属性:
namespace MVCApp.Models
{
public class Ticker
{
public string Symbol {get; set;
public string Exchange {get; set;}
}
}
namespace Domain //in another assembly
{
public class Quote
{
public string Symbol {get; set; }
public string Exchange {get; set; }
//lots of other properties we need for output
}
}
public ActionResult ShowQuote(Ticker ticker)
{
var quote = quoteRespository.GetQuoteBy(ticker);
return View(quote);
}
在视图中,他们可以指定Ticker和Exchange;那是使用DefaultModelBinder
的ModelBound。但是,每次我们需要实际使用此Ticker
对象时,我们需要转到QuoteRespository
并获取为该Ticker填充的所有属性。
我应该摆脱Ticker
对象,只需创建一个自定义模型绑定器来模型绑定到Quote
对象;并在Modelbinder中使存储库调用实际填写Quote
对象?或者我是否应该违反DRY并在每个需要报价的地方拨打该存储库?是否有一种内置的框架方式可以解决这个问题?
似乎有一种思想流派可以说not to make service-layer calls in the Modelbinder。
我创建了Ticker类只是因为我们在(几乎)每个动作中都有这两个属性:
public ActionResult ShowQuote(string symbol, string exchange)
由于它们总是在一起,我在UI层创建了一个小型的Model类来将它们推到一起(前面提到的Ticker
类)。 Ticker不是视图模型类,并不意味着。
答案 0 :(得分:1)
“或者我是否应该违反DRY并在我们需要引用的每个地方调用该存储库?是否有内置的框架方式来执行此操作我不知道?”
您可以随时检索报价作为Quote控制器OnActionExecuting功能的一部分。
我不认为这是干扰。只是做生意的成本。有可能你检索报价的方式不会改变,你可能会有<你需要10个地方这个功能。取决于您需要包含该行的次数。
最好采用简短而简洁的操作方法,而不是在基本控制器中执行所有操作并执行操作。
不要进入针对您的存储库的模型绑定。它是在之前的项目中完成的,也是应用程序中最糟糕,最脆弱的部分。
答案 1 :(得分:0)
我会使用AutoMapper在视图模型和域模型之间进行映射。
答案 2 :(得分:0)
对我而言,了解Quote
包含哪些内容非常重要?你提到它有输出的其他属性,但它是否有其他属性和方法只与Domain
命名空间相关?如果是,那么我想在用于视图的类型和域命名空间中的类型之间保留一个抽象。
因此,您最终可能会得到TicketViewModel
,其中包含您的观看所需的所有内容,正如Darin所提到的,使用AutoMapper将TicketViewModel
映射到Quote
。
修改强>
如果您确实想要确保DRY,那么您可以创建自己的ModelBinder(这很容易,Google上的大量教程)并将您的viewmodel与其中的存储库绑定。