在域和存储库之间共享实用程序对象

发布于 2024-11-30 00:52:59 字数 969 浏览 0 评论 0原文

我目前正在构建一个使用 MySQL 数据库的框架。我无法使用实体框架的 MySQL 实现,因此我试图找出通用搜索和分页功能的最佳方法。

最简单的解决方案是使用带有签名的存储库方法,例如:

IList<Blah> GetSomething(string _query, 
                         int _page, 
                         int _pageSize, 
                         out int _numPages)

但这似乎有点反 OOD。

我的一个想法是创建一个带有 ISearchParameter 和一个 IPaging 对象的实用程序 dll,域级别和存储库级别都可以访问,这将避免重新创建这两个对象每个域和存储库中的接口及其实现。

public interface ISearchParameters
{
    Direction Direction { get; set; }
    string DirectionField { get; set; }
    string Query { get; set; }
    IList<string> SearchFields { get; set; }
}

public interface IPaging
{
    int CurrentPage { get; set; }
    int PageSize { get; set; }
    int NumberOfPages { get; set; }

    int GetQueryPage();
}

我通常会将 DTO 从存储库映射到域对象,但如果两个级别都引用此实用程序 .dll,那么在这两个级别之间传递 ISearchParameter 对象而不进行映射会是一个糟糕的设计吗?如果是的话,还有更好的解决方案吗?

I'm currently building a framework that uses a MySQL database. I can't use the MySQL implementation of the entity framework, so I'm trying to figure out the best way of generalising search and paging functionality.

The simplest solution would be to have repository methods with signatures such as:

IList<Blah> GetSomething(string _query, 
                         int _page, 
                         int _pageSize, 
                         out int _numPages)

but this seems slightly anti-OOD.

An idea I had was to create a utility dll with an ISearchParameter and an IPaging object that both the domain level and repository level could access, this would avoid having to recreate these two interfaces and implimentations of them in each domain and repository.

public interface ISearchParameters
{
    Direction Direction { get; set; }
    string DirectionField { get; set; }
    string Query { get; set; }
    IList<string> SearchFields { get; set; }
}

public interface IPaging
{
    int CurrentPage { get; set; }
    int PageSize { get; set; }
    int NumberOfPages { get; set; }

    int GetQueryPage();
}

I'd usually map DTOs from the repositories to domain objects, but if both levels referenced this utility .dll, would it be bad design to pass ISearchParameter objects between these two levels without mapping? If so, are there any better solutions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

债姬 2024-12-07 00:52:59
  1. 使用存储库模式抽象出与数据访问层的交互。
  2. 使用控制反转容器创建存储库,以避免从域引用数据访问层。
  3. 然后,数据访问可以保存对域类或域类工厂的引用,从而避免对 DTO 的需要(遵循 DRY 原则)。
  4. 将您的接口设计为无状态的。当跨层(可能成为层)时,考虑服务而不是对象。这更喜欢更简单的方法。
  5. 避免使用 utility.dll。您实际上只需要在域和数据访问层之间共享存储库接口。您可以将它们放在域程序集中,或者更好的是,将它们放在单独的程序集中。
  1. Use the Repository Pattern to abstract away your interaction with data access layer.
  2. Use an Inversion of Control container to create your repository, to avoid a reference from your domain to data access layer.
  3. The data access can then hold a reference to your domain classes, or to the domain class factories--avoiding the need for DTOs (following the DRY principle).
  4. Design your interfaces to be stateless. When crossing layers (which may become tiers), think of services instead of objects. This would prefer the simpler approach.
  5. Avoid having a utility.dll. You really only need to share your repository interfaces between your domain and data access layer. You could put those in your domain assembly, or better, a separate assembly.
心碎无痕… 2024-12-07 00:52:59

在我看来,这是一个非常合适的解决方案。在我的项目中我经常使用jqGrid,当然它也有搜索、排序和分页功能。我使用 gridParameters 对象(在我的基础设施层中定义),该对象从控制器 (UI) 传递到业务层和数据层。
这些对象不包含任何业务规则,因此我认为这种方法没有任何问题。

In my opinion this is a perfectly suitable solution. In my projects I use jqGrid a lot, which ofcourse also has search, ordering and paging. I use a gridParameters object (defined in my infrastructure layer), which is passed from the controller (UI) to the business layer and the data layer.
The objects don't contain any business rules, so i don't see any problems with this approach.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文