1

我有一个 GenericDAO，它将其操作委托给 DataSource 类

public class BaseDAOImpl<T> implements BaseDAO<T> {     
    DataSource ds;      

    public T update(T entity) {
    ds.update(entity);
    }

我现在遇到的问题是我们希望它与多个数据源一起工作。这给我留下了 2 个选择

1）在DAO中为数据源创建一个setter并在每次操作之前使用它

2) 每个数据源数量创建 BaseDAO 的每个子节点 n 次

我希望 DataSource 退出 DAO，但是如何将操作委派给它呢？

4

4 回答 4

1

您可以使用工厂来创建数据源，因此根据您的要求创建数据源，然后是否可以使用依赖注入将数据源注入 DAO。

要摆脱 DAO 中的数据源，您可以使用委托模式，在您的 DAO 中注入委托者，您的委托将具有数据源的引用。

另请注意，如果您只使用一个通用 DAO，您的 DAO 最终可能会被非通用但更特定于应用程序的某些功能的方法弄脏，恕我直言，您还应该考虑将 DAO 分解到更具体的级别，留下通用的DAO 实际上做的是通用工作。

于 2012-05-22T06:37:19.783 回答
1

我猜你想实现类似多租户的东西：当请求来自用户 A 时，所有参与处理该请求的 DAO 都应该与用户 A 对话DataSource，依此类推。

如果是这样，DataSource是您请求的上下文的一部分，存储这种上下文数据的一个可能选项是使用ThreadLocal：

  • 当请求到来时，您将适当的DataSource放入ThreadLocal
  • 所有 DAO 都从中DataSource获得ThreadLocal.
    显然，为了单一职责原则，最好将此逻辑隐藏在工厂后面并将该工厂注入您的 DAO 中，以便 DAO 将调用factory.getCurrentDataSource()每个操作。
  • ThreadLocal完成请求处理后清除。

请注意，它仅在每个请求由单个线程处理时才有效。

于 2012-05-22T08:48:35.457 回答
0

我不会对数据源使用 setter，而是将它传递给 DAO 的构造函数。在 DAO 对象的生命周期内更改数据源似乎是不对的。

于 2012-05-22T07:00:54.000 回答
0

好吧，我认为，在这种情况下，您应该尝试使用依赖注入。您的基类将从数据源类型中抽象出来。因此，即使您要添加一种新类型的数据源，您最终要做的唯一更改将是工厂方法，该方法将根据当前请求生成一种 DataSource 对象，从而增加应用程序的松散耦合

interface IDataSource<T>
{
    T update<T>(T entity);
}

public ConcereteDataSource<T> : IDataSource<T>
{
    public T update<T>(T entity)
    {
        //Concerete implementation
    }
}


public class BaseDAOImpl<T> implements BaseDAO<T> 
{     

    public IDataSource ds {get;set;}
    public T update(T entity) {
    ds.update(entity);
}

//where you try to instansiate a new instance of Base DAO

//Factory to create a new instance of datasource for this context
IDataSource contextualDs = GetDataSourceForThisUser();

BaseDAOImpl<SomeType> dao = new BaseDAOImpl<SomeType>();
//inject the dependency
dao.ds = contextualDs;
于 2012-05-22T11:55:04.720 回答