API设计和DAO模式
我需要为应用程序创建一个 API（比如库管理器）。与许多典型应用程序一样，它是在 ORM 工具之上构建的，该工具使 POJO 持久化到 dbms 中。 现在我必须制作 API，以便其他开发人员可以将其作为 JAR 使用。比方说，我们希望用户将书籍添加到图书馆。 我对设计它的最佳方法有很多疑问。
1) 为 POJO 提供类似于 DAO 的类是个好主意吗：
<代码> 图书管理器{ 创造（...） 删除（书本）； 列表<书籍>获取全部（）； ... 2
) 公开对象：
a) 我应该向 API 层公开实际的应用程序 POJO 吗？ 它们有一些可能不想公开的应用程序逻辑和一些我想公开的逻辑。例如，我想公开 book.getPages() 但不公开 book.deletePage(int pageNo)
b) 专门为 API 层创建重复对象。仅暴露接口。
c) 根本不暴露对象。 API 使用参数。例如
<代码> 图书管理器{ 创建（字符串名称，整数价格）； 删除（字符串名称）； 列表<对<字符串、整数>>获取全部（）； ... }
这意味着系统的单点访问。如果要对 POJO 执行某些操作，将从 BookManager 调用。例如，ClockManager.start（字符串时钟名称）。它还提供了灵活性，例如 ClockManager 中具有 startAll() 等方法。
3) 最后，BookManager 应该包含 update() 方法，还是应该存在于 Book 本身中？更新意味着将配置保存到数据库中。什么更有意义：
Book book = bookManager.create("API设计"); 书.setPrice(); book.update();
或者，
Book book = bookManager.create("API设计"); 书.setPrice(); bookManager.update(book);
提前致谢，
安缦
I need to make an API for an application (lets say Library Manager). Like many typical applications, it is made on top of an ORM tool which makes POJOs being persisted into dbms.
Now I have to make API so that other developers can use it as a JAR. Lets say, we want users to add books to library.
I have many questions about the best way to design it.
1) Is it a good idea to have DAO like classes for POJOs :
BookManager {
create(...)
delete(Book book);
List<Book> getAll();
...
}
2) Exposing objects:
a) Should I expose actual application POJO's to API layer?
These have some application logic which may not want to expose and some logic which I want to expose. For example, I want to expose book.getPages() but not book.deletePage(int pageNo)
b) Create duplicate objects specially for API layer. Only interface will be exposed.
c) Not expose Objects at all. API is used using parameters. For example
BookManager {
create(String name, int price);
delete(String name);
List<Pair<String, Integer>> getAll();
...
}
This means, single point of access with the system. If some operation is to be performed on the POJO, it will be called from BookManager. For example, ClockManager.start(String clockName). It also give flexibility like having methods like startAll() in ClockManager.
3) Finally, should BookManager contain a method for update(), or it should be present in Book itself? update means saving the configuration into the database. What makes more sense :
Book book = bookManager.create("API Design");
book.setPrice();
book.update();
Or,
Book book = bookManager.create("API Design");
book.setPrice();
bookManager.update(book);
Thanks in advance,
Aman
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短回答：
不一定。我不会让我使用的 ORM 工具决定我的设计。你没有说你用的是什么工具，但是好的工具非常灵活，几乎可以持久任何 POJO 设计。
选择 b)。不要公开超出您需要的内容，但公开对象比引入 c) 中使用的间接类型要好
第一个选项更好。
事实上，我并不确定我给你的建议是否正确。原因是它们需要考虑很多权衡。这是我根据我对你的项目的了解得到的最好的建议...
我维护一个关于 API 设计的网站：
http:// theamiableapi.com/
您可能还想读一两本书。查看菜单中的“资源”下。 (Jaroslav Tulach Ferenc) 的那幅
约书亚·布洛赫 (Joshua Bloch) 的那幅，或者雅罗斯拉夫·图拉赫·费伦茨
Short answer:
Not necessarily. I wouldn't let the ORM tool I use dictate my design. You did not say what tool are you using, but good ones are very flexible and can persist almost any POJO design.
Choose b). Do not expose more than you need, but it is better to expose objects than to introduce the kind of indirection used in c)
3) The first option is better.
I'm actually not as sure that I'm giving you the right advice as I might sound. The reason being that they are many tradeoffs to consider. This is the best advice I have based on what I know about you project...
I maintain a website about API design:
http://theamiableapi.com/
You might also want to read a book or two. Look under Resources in the menu. The one by Joshua Bloch or perhaps the one by Jaroslav Tulach
Ferenc
我不禁觉得，出现一些问题是因为您的 POJO 包含更接近 ActiveRecord 之类的功能。作为包含“.GetPages()”方法的示例书。如果它是真正的 POJO，那么它已经加载了页面（或者对 DAO 的隐藏引用，以便它们可以延迟加载）。同样，当您删除页面时，此时您不需要了解 DAO。您从书中删除该页面，然后将书保存到 BookDAO。另外，我不推荐您通过 API 公开的任何 POJO 的延迟加载方法。
尝试准确回答您的问题：
类似的事情我认为是的。
显然选项 (c) 最有可能被所有消费者使用。如果您正在调用 API 并且希望删除一本书，您是否确实希望首先传递该书，或者您只想传递 ID 或名称（您可能已经拥有）。
BookManager 应该有更新（Book book）。如果您将 Update 放在 Book 上，那么您就从 POJO 中删除了 ActiveRecord 类型的功能。在适当的情况下，两者都可以，但混合总是令人困惑。
注意：对于（3），完整的活动记录类型将是
I can't help but feel that some of the questions that raise come about because your POJO contains functionality closer to something like ActiveRecord. As an example Book containing ".GetPages()" method. If it was a true POJO it would already have pages loaded (or a hidden reference to the DAO so they can be lazy loaded). Similarly when you delete a page, you don't need to know about the DAO at that point. You remove the page from the book then save the book to the BookDAO. Also I wouldn't recommend the lazy loading approach of any POJO that you expose through your API.
To try and answer your questions exactly:
Something like that I think yes.
Obviously option (c) has the most potential to be used by all consumers. If you're calling your API and you wish to delete a book, do you really want to get the book first to pass in, or do you just want to pass in the ID or name (which you may already have).
BookManager should have Update(Book book). If you put Update on Book then you are crossing out of POJO into ActiveRecord type functionality. Either are OK in the right situation, but a hybrid is always confusing.
Note: for (3) a full active record type would be