将参数传递到存储库,同时保持关注点分离
我是 mvc 新手,整个编程方式对我来说非常陌生,所以要温柔......
我的文章存储库中有:
public IQueryable<Article> GetArticles(int? category, int? position)
{
return from a in dc.Articles
where a.LanguageIndex == lang && a.CategoryIndex == category && a.ArticlePosition == position
select a;
}
如何在保持关注点分离的同时从界面传递参数类别和位置?
我考虑过:
public interface IArticleRepository
{
IQueryable<Article> GetArticles(Article a);
}
并将参数与 Article 对象一起传递,但这意味着我必须传递控制器中的类别和位置。 我在这里的方向正确吗?
I'm new to mvc and this whole way of programming is pretty unfamiliar for me, so be gentle ...
I have in my article repository:
public IQueryable<Article> GetArticles(int? category, int? position)
{
return from a in dc.Articles
where a.LanguageIndex == lang && a.CategoryIndex == category && a.ArticlePosition == position
select a;
}
How can I pass the parameters category and position from the interface while maitaining separation of concerns ?
I thought about :
public interface IArticleRepository
{
IQueryable<Article> GetArticles(Article a);
}
and passing the parameters along with the Article object, but this means I would have to pass the category and position in the controller.
Am I in the right direction here?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不确定这与关注点分离有何关系。我可以看出抽象在哪里可能存在漏洞;您是否担心用户似乎对存储库如何保存您的文章了解得太多?
在有人想出一种将实现与模型分离的高性能方法之前,存储抽象将始终存在泄漏。你可以为此打败自己,或者尽你最大的努力去解决。
恕我直言,你的第二种方法比第一种方法更糟糕。您仍然必须在文章中规定类别和位置,因此除了将参数与实体混淆的奇怪 API 之外,您仍然存在泄漏。
我肯定会选择第一个版本而不是第二个版本。如果我要做任何事情,我会重构以创建 CategoryIndex 和 ArticlePosition 实体(链接到 Article 表的 Category 和 Position 表)。然后,您可以将 API 重构为更具吸引力:
这比您已有的更好吗?可能不会。
Not sure how this relates to separation of concerns. I can see where it might seem the abstraction is leaky; is it your concern that it seems users must know a little too much about how the repository holds your Articles?
Until someone comes up with a performant method of separating implementation from models, storage abstractions will always be leaky. You can beat yourself up over it or just do your best and deal.
Your second method is, IMHO, worse than the first. You still have to stipulate the category and position in your Article, so you still have the leak in addition to a weird API that confuses parameters with entities.
I'd definitely go with the first version over the second. If I were to do anything, I would refactor to make CategoryIndex and ArticlePosition entities (Category and Position tables linked to the Article table). You could then refactor your API to the more appealing:
Is this any better than what you already have? Probably not.
首先,我将分离出基本查询:
现在,如果您想将特定查询过滤器移出存储库,您可以将其移至扩展方法:
Fist I would separate out the basic query:
Now if you want to move the specific query filter out of your repository you can move it to an extension method: