设计模式/数据加载解决方案

Question

我一直在处理涉及数据加载的几个项目，有时是远程加载，有时是本地加载，有时是JSON格式，有时是XML格式。我遇到的问题是由于开发速度过快和各种客户不断变化的想法，我的设计过于死板，我希望它们更加灵活。我一直在尝试想出可重用的数据加载解决方案，并希望得到一些建议，因为我想你们中的许多人都遇到了同样的问题。

我想做的是创建一个通用的LoadingOperation抽象类，它具有类型为Parser和Loader的成员变量，这些变量分别具有parse()和loadData()方法。 Parser和Loader类是接口和实现这些接口的类，例如XMLParser和JSONParser，LocalLoader和RemoteLoader等。使用类似这样的东西，我想为每个要加载的东西创建一个扩展LoadingOperation的新类，无论是本地XML文件还是远程JSON或其他任何内容。

问题是特定的Parser实现不能返回自定义数据类型，否则会破坏LoadingOperation类的多态行为。我一直在尝试使用泛型并声明LoadingOperation的子类，例如：

class SpecificLoader extends LoadingOperation<CustomDataType>

我正在使用解析器类进行类似的操作，但这似乎有点奇怪。是否有人能提供任何关于我做错了什么/可以做得更好的建议呢？我想能够快速地对变化的规格做出反应（忽略它们不应该变化得那么多的事实！），并且对代码进行逻辑分离等等...... 感谢任何帮助！ 编辑：问题也在这里link text被问到。

- Dori

---

你是否正在处理来自不同来源的相同数据？也就是说，你是否正在使用这些数据填充相同的业务模型对象？如果不是，我怀疑整个方法的意义... - Jules

我的想法是，这将是处理本地数据、Web服务等重复使用的模式（这些是开发时间短暂的小型移动应用程序，并且原型通常只有本地数据等）。对于每个项目来说，它都是来自可变源的相同数据，但对于不同的项目，则明确是不同的数据和模型！ :) - Dori

抱歉，我看不出这应该如何工作。解析是按照您的业务逻辑处理数据，显然这种逻辑和数据会发生变化，因此您在某些时候需要特定的方法。一层又一层地构建，直到进行特定转换将没有任何好处。对我来说唯一有意义的抽象层是如果您包装解析器的细节，以便只有高级别调用myObject = loadData(); 或loadData（myObject）;，以便您可以快速替换实际的解析器实现。 - Jules

Answer 1

听起来你真的想要一些软类型的东西，尽可能少的代码，因为需求变化太快了。这是我如何处理我的一个项目，我在后端使用PHP。我使用sql和json快速从数据库中获取数据并返回给客户端。

通常我在数据库中进行选择，对于每个结果行，我将该行转换为一个映射，其中每个列都成为键，值为该列的结果。这些映射列表然后通过通用json例程转换为json，并从服务器发送json。

这样的设置非常容易将一些数据从服务器传输到客户端，但是：

• 您会失去使用hibernate/xml/remoting可以获得的类型安全性。
• 您的客户端与您的数据库模式紧密耦合。
• 它非常快速地获取数据并传输数据。
• 如果更改查询以获取更多数据，则无需重新编译客户端，除非他们需要使用新数据。

为了让您了解这在PHP中是什么样子，我做了：

在我的数据访问对象中：

function getAllPortal() {
    $sql = "select firstname, lastname, U.* from person, portal_user U where id=person order by firstname, lastname";
    $prep = $this->db->prepare($sql);
    return $prep->execute();
}

而在我的HTTP服务（基于REST）代码中：

    $accPerson = new AccountPerson($db);
    echo json_encode($accPerson->getAllPortal());

在Java中，您可能需要创建一些框架来将数据以列表映射（或其他易于传输到客户端的结构）的形式提取出来。我在PHP中制作了一个这样的框架，它还允许使用预处理语句。

您可以考虑一些其他方面（即使您不按照上述方式操作），例如：

避免层次结构。尽可能少地使用它们。如果您使用Hibernate，请拥抱它。直接在查询中使用对象并将其转换为json并输出。如果多个人（或客户端）需要使用您的数据，则层使您的代码更加健壮-它们使您的代码不愿意快速更改。知道何时使用层以及何时不使用是诀窍，并尽可能抵制它。编写层需要时间。

选择XML或更好的JSON作为传输格式。不要选择像xml这样阻止更改的模式或将其序列化为pojos。Pojos非常适合业务逻辑，但对于数据传输而言则不太理想。如果您的客户端足够简单，则不必将json反序列化为对象。直接使用JSON即可。与层一样，诀窍在于知道何时重新创建pojos会产生业务价值，何时不会。与层一样，抵制投入这项工作，直到您看到价值为止。编写/维护反序列化器需要时间。

- Knubo