我正在考虑使用Joda-Time 我想知道我是否应该注意我的界面正在返回什么类型的对象 从服务层上的界面签名返回Joda-Time对象意味着使用它的每个模块都将依赖于Joda-Time而不是常见的java.util.Date API。 您是在App模块周围传递Joda对象还是在应用程序的特定部分编写包装器？
答案 0 :(得分：4)
有什么替代方案？将jodaTime对象转换为臭名昭着的Calendar / Date对象？
你选择摆脱这些对象，这是一个很好的决定。现在，如果你让其他层使用java date API，它们将会使用jodaTime来解决你摆脱的错误和非感性行为。
我认为你应该帮助你的用户，让他们使用jodaTime。
当然，这是一个设计决策，它会在代码中添加对jodaTime的依赖，但我发现它没有问题，因为你选择了jodaTime来编写更少更好的代码，所以应该这样做。
答案 1 :(得分：4)
一开始，只返回最合适的类型（在这种情况下为Joda Objects）。
如果您了解某人有问题（可能不会经常发生），请在界面中添加转换器方法（例如，getTime()和{{1} }或getJavaTime()）。
或者添加一个通用的辅助方法，该方法接受一个Object（您可以在代码中的任何位置将未知实例视为getTimeInMillis()，而无需导入实际的Joda类）并返回一个普通的Java对象（{{1 }}）。
答案 2 :(得分：0)
尽可能使用Joda-Time。转换为java.util.Date，其中需要与其他非Joda-Time精明的类交换数据。
从java.util.Date转到org.joda.time.DateTime，将Date传递给DateTime构造函数：
DateTime myDateTime = new DateTime( myDate );
要从DateTime转到Date，请调用toDate方法：
Date myDate = myDateTime.toDate();
Java 8带来了JSR 310定义的java.time。*类。这些类的灵感来自Joda-Time，但完全重新构建。
如果您的项目仅在Java 8或更高版本中使用，请使用这些而不是Joda-Time。 Joda-Time在旧版Java上仍然有用，Joda-Time仍然可以使用。但java.time。*类旨在取代Joda-Time和java.util.Date/Calendar类。
随着其他类和框架的更新，用java.time。*替换它们对java.util.Date/Calendar的使用，你的问题最终会变得毫无意义。
答案 3 :(得分：0)
根据您希望客户端库对您的API执行的操作，您可以选择使用仅毫秒时间戳。所有其他的代表可能或可能不值得传递。如果你的库是以人类可辐射的方式帮助表示日期和时间，那么使用Joda，它可能在Java8中的工作方式大致相同。如果您的图书馆更多地与日期进行争论，请在几毫秒内交换时间并留给客户使用他们喜欢的任何内容。