Question

我需要为应用程序创建一个API（比如库管理器）。与许多典型应用程序一样，它是在ORM工具之上制作的，这使得POJO被持久化为dbms。现在我必须创建API，以便其他开发人员可以将其用作JAR。可以说，我们希望用户将图书添加到图书馆。我对设计它的最佳方法有很多疑问。

1）让DAO像POJO类一样是个好主意：
BookManager { create(...) delete(Book book); List<Book> getAll(); ... }

2）暴露物品：

a）我应该将实际应用程序POJO暴露给API层吗？它们有一些可能不想公开的应用程序逻辑和我想要公开的一些逻辑。例如，我想公开book.getPages（）但不公开book.deletePage（int pageNo）

b）专门为API层创建重复对象。只会显示界面。

c）根本不暴露物体。 API使用参数。例如

BookManager { create(String name, int price); delete(String name); List<Pair<String, Integer>> getAll(); ... }

这意味着，系统的单点访问。如果要在POJO上执行某些操作，将从BookManager调用它。例如，ClockManager.start（String clockName）。它还具有灵活性，例如在ClockManager中使用startAll（）等方法。

3）最后，BookManager是否应该包含update（）方法，或者它应该出现在Book本身中？更新意味着将配置保存到数据库中。更有意义的是：

Book book = bookManager.create("API Design"); book.setPrice(); book.update();

或者，

Book book = bookManager.create("API Design"); book.setPrice(); bookManager.update(book);

提前致谢，
阿曼

Answer 1

我不禁觉得有些问题引发了，因为你的POJO包含的功能更像ActiveRecord。作为示例Book包含“.GetPages（）”方法。如果它是一个真正的POJO，它已经加载了页面（或者对DAO的隐藏引用，因此它们可以延迟加载）。同样，当您删除页面时，您不需要知道DAO。您从书中删除页面，然后将书保存到BookDAO。此外，我不建议您通过API公开的任何POJO的延迟加载方法。

试着准确回答你的问题：

我想是的。
显然，选项（c）最有可能被所有消费者使用。如果你正在调用你的API而你想删除一本书，你真的想先把这本书传入，或者你只想传递你的ID或名字（你可能已经拥有）。
BookManager应该有更新（书本）。如果你把更新放在Book上，那么你就会越过POJO进入ActiveRecord类型的功能。在正确的情况下都可以，但混合动力总是令人困惑。

注意：对于（3），完整的活动记录类型将是

Book book = Book.Load("API Design"); book.SetPrice(45); book.Update()

Answer 2

简短回答：

不一定。我不会让我使用的ORM工具决定我的设计。你没有说你使用的是什么工具，但好的工具非常灵活，几乎可以坚持任何POJO设计。
选择b）。不要暴露超出你需要的东西，但暴露对象比引入c）中使用的间接方式更好

3）第一种选择更好。

我实际上并不确定我能给你正确的建议。原因是他们需要考虑很多权衡。根据我对你的了解，这是我最好的建议......

我维护一个关于API设计的网站：

http://theamiableapi.com/

您可能还想阅读一两本书。在菜单中的Resources下查看。 Joshua Bloch或者Jaroslav Tulach的那个人

Ferenc

API设计和DAO模式

2 个答案: