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

时间:2010-12-01 21:00:00

标签: java design-patterns

我一直致力于一些涉及加载数据的项目,有时是远程的,有时是本地的,有时是JSON,有时是XML。我遇到的问题是,由于开发的速度和各种客户的不断变化,我发现我的设计过于僵化,我希望它们更灵活。我一直试图想出一个可重用的数据加载解决方案,并且想要一些建议,因为我想你们中的很多人都有同样的问题。

我想要做的是创建一个通用的 LoadingOperation 抽象类,其成员变量类型为 Parser Loader ,其中分别有parse()和loadData()方法。 Parser Loader 分类是接口,实现它们的类可以是XMLParser和JSONParser,LocalLoader和RemoteLoader等。有了这样的东西,我希望有一个新类为每个要加载的东西扩展 LoadingOperation ,为本地XML文件或远程JSON或其他任何东西提供天气。

问题是特定的 Parser 实现无法在不破坏 LoadingOperation 类的多态行为的情况下返回自定义数据类型。我一直在搞乱泛型并声明 LoadingOperation 的子类,如

class SpecificLoader extends LoadingOperation<CustomDataType>

使用 Parser 类做类似的事情,但这看起来有点奇怪。

有没有人对我做错什么/可能做得更好有任何建议。我希望能够对不断变化的规范做出快速反应(忽略它们不应该改变那么多的事实!)并且具有逻辑上的代码分离等......

感谢您的帮助!

编辑:问题也在这里问link text

1 个答案:

答案 0 :(得分:1)

对我来说,你真的想要一些用尽可能少的代码轻轻打字的东西,因为需求变化太快了。这是我如何做我的项目,我在后端使用PHP。我使用sql和json快速从数据库中获取数据并返回给客户端。

通常我在数据库中执行select,对于每个结果行,我将行转换为一个映射,其中每列成为键,其值为该列的结果。然后通过通用的json rutine将这个映射列表转换为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服务(基于休息)代码中:

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

要在Java中执行此操作,您可能需要创建一些框架,以便在地图列表(或您希望传输到客户端的其他简单结构)中获取数据。我在PHP中创建了一个允许使用预准备语句的文件。

您可以考虑的

其他一些注意事项(即使您没有这样做)可能是:

避免使用图层。尽可能少。如果你使用Hibernate - 拥抱它。直接在查询中使用对象并将它们转换为json并将其发送出去。如果有几个人(或客户)需要使用您的数据,这些层会使您的代码变得健壮 - 它们使您的代码不愿意快速更改。知道何时进行分层以及何时进行分层是诀窍并且只要你可以抵抗它。编写图层需要时间。

使用XML或更好的JSON作为传输。不要选择能够抵制像xml和/或序列化更改为pojos的模式。 Pojos非常适合业务逻辑,但数据传输很糟糕。如果您的客户端足够薄,请不要再次将您的json反序列化为对象。直接使用JSON。同样,与图层一样,诀窍是要知道何时重新创建pojos会给出商业价值,何时不会。与图层一样,在你看到价值之前,要坚持投入工作。编写/维护反序列化器需要时间。