对象列表设计模式的接口?



我目前正在从事一个涉及员工对象列表的项目。我通过使用休眠从员工数据库中读取来生成此列表。

现在我的问题是,当前的系统只是传递一个员工对象列表,但我不确定这是最好的方法。

我现在所做的是创建一个 EmployeeManager 对象,该对象负责创建、删除、搜索和更新员工列表。

这是最好的方法吗?或者只是另一个不需要的抽象,传递列表就可以了?

是的,您正在做的是一种存储库模式。

使用存储库模式可实现以下一个或多个目标:

  • 您希望最大化可通过自动化测试的代码量,并隔离数据层以支持单元测试。
  • 您可以从多个位置访问数据源,并希望应用集中管理、一致的访问规则和逻辑。
  • 您希望实现和集中数据源的缓存策略。
  • 您希望通过将业务逻辑与数据或服务访问逻辑分离来提高代码的可维护性和可读性。
  • 您希望使用强类型的业务实体,以便可以在编译时而不是运行时识别问题。
  • 您希望将行为与相关数据相关联。例如,您希望在实体内的数据元素之间计算字段或强制实施复杂的关系或业务规则。
  • 您希望应用域模型来简化复杂的业务逻辑。 请考虑 UnitOfWork 模式以及存储库模式。

来自 :https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff649690(v=pandp.10(

答案是:视情况而定。

但通常最好创建另一个抽象层并在进一步的类/实现等中使用它。

为什么?好吧,想象一下,无论出于何种原因,您都需要使用另一种技术更改数据库层;只需修改上述图层,这将为您节省大量时间。 而且,您不应该滥用和制作太多图层。这实际上取决于某些情况,您应该选择最适合您的方法。

在"我应该如何编写代码"这个领域有很多资源。

  • R.C. 马丁 - 清洁代码
  • R.C. Martin – 敏捷软件开发。原则模式和实践
  • E.伽玛,R.
  • 赫尔姆,R.约翰逊,J. Vlisside - 设计模式:可重用的面向对象的元素 软件

我建议您阅读一些并发表自己的意见。在某些情况下可能需要妥协。

最新更新