Question

我已经为我的项目采用了存储库/服务设计模式，当我构建它时，我心想。

获取存储库的所有项目（将其保存在缓存中）然后使用LINQ进行过滤而不是使用数据库连接进行每次调用更好。

例如，我有这个：

public Asset Get(int id)
{
    return GetAll().Where(a => a.Id == id).FirstOrDefault();
}

public IList<Asset> GetAll()
{
    return AssetData.Get(userId, companyId);
}

而不是：

public Asset Get(int id)
{
    return AssetData.Get(id, userId, companyId);
}

public IList<Asset> GetAll()
{
    return AssetData.Get(userId, companyId);
}

我认为第一个是最好的，因为它会加速系统，并且会有更少的数据库连接/查询。

那么，有人可以向我解释这种情况的最佳做法吗？

Answer 1

这是不成熟的优化。在您开始使用该应用程序之前，您不知道瓶颈会在哪里。等到你开始获得性能命中，然后看看你可以做些什么来提高性能。您也是第二个猜测许多服务每天使用的成熟技术。如果处理得当，数据库相当强大且性能极高。

通过将您的存储库放在接口后面，您已经做了正确的事情。这使您可以灵活地更改实施，而无需更改消耗代码。考虑使用内置NHibernate的caching等ERM解决方案。没有必要重新发明其他人一直在改进的轮子。

Answer 2

正如@Brian评论的那样，最重要的问题是什么最适合你和你的特定场景。我（个人）要小心缓存任何有可能在请求之间失效的应用程序数据，即用户在您的情况下更新了资产记录，但因为它被缓存，您的用户将无法看到更新，直到缓存已过期或已刷新（这只会让人感到困惑！）。

然而，我在最近的应用程序中使用了类似的技术，我使用缓存的查找数据来填充返回DTO中的描述值。在测试期间，这比跨越10个表的DB查询要快得多，以获得这些值。我使用的查找数据变化很少，但为了以防万一，我在30分钟后将缓存过期。

我认为您还需要意识到过早优化并可能尝试解决您可能实际上没有的问题。

数据库连接（最佳实践）

2 个答案: