---
title: "Discussion on \"RavenDB Lessons Learned - Part 2\" | Hashnode"
description: "Discussion on \"RavenDB Lessons Learned - Part 2\". A continuation of my lessons learned on RavenDB. Some tips on testing and what not to do.\n1. Testing Indexes is Really Really Really Important\nOne of the best features in RavenDB, is the ability to use a full in-memory database when running your inte..."
url: "https://hashnode.com/posts/ravendb-lessons-learned-part-2/619d241206cdc0324d914d16"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [RavenDB Lessons Learned - Part 2](https://gaunacode.com/ravendb-lessons-learned-part-2?utm_source=hashnode&utm_medium=feed)

A continuation of my lessons learned on RavenDB. Some tips on testing and what not to do. 1. Testing Indexes is Really Really Really Important One of the best features in RavenDB, is the ability to use a full in-memory database when running your inte...

Mar 13, 2017 · 4 min read · gaunacode.com  
Read the article

-   [#nosql](https://hashnode.com/tag/nosql)

## Written by

[Facundo Gauna](https://hashnode.com/@gaunacode)

@gaunacode · Orlando, FL

  
[View profile](https://hashnode.com/@gaunacode)

Building cloud-native apps on Azure. I can't stop self-improving.

I used to be a .NET developer. Nowaways, I am a DevOps solutions architect with a focus on Azure and Kubernetes. I also love productivity topics, especially when it comes to doing more with less of my time. I'm also a daddy, so time is a limited resource for me.

## Responses 1

Markdown supported · ⌘↵ to post

[Denny Crane](https://hashnode.com/@dasjestyr)

[Oct 12, 2022](https://hashnode.com/posts/ravendb-lessons-learned-part-2/619d241206cdc0324d914d16/comment/63472aca81c6df26fb022831)

Was your experience in using RavenDB on a desktop application? I ask because my experience contradicts a few of yours:

-   You can control transaction scope with repository pattern, but you do it by abstracting a UoW as well. Basically something similar to DbContext where you have a single interface that contains properties that are all of your collection repositories. This UoW takes the session as a ctor and passes that into all of the other repositories as they're requested. Then in your repos, you just never call save changes. So then in your service, you request the UoW instead, and you can work across whatever collections you want and call savechanges whenever you want. It has worked very well for me.
-   I also implemented a base repository for crud operations and have no issues with sessions. What I do is inherit them on repos that can perform crud operations and extend them with the repo's interface for more bespoke operations. So when you request the repo/collection in your service, you'll have both.

My implementations were for web services, desktop applications. I did have a problem with sessions when I tried to access the database directly from Blazor because it uses a single session for the entire SPA. There were two solutions for it though:

-   When requesting the repo via DI, make sure you're getting back a new scope every time.
-   Move all database operations out of the UI and into an API which is what I ended up doing for other reasons. Since the API is stateless, this problem works itself out.

[Facundo Gauna](https://hashnode.com/@gaunacode)

[Oct 31, 2022](https://hashnode.com/posts/ravendb-lessons-learned-part-2/619d241206cdc0324d914d16/comment/63472aca81c6df26fb022831#reply-635fa1f2d6a4875d1a1f3e4c)

[Denny Crane](https://hashnode.com/@dasjestyr) - Hey there!

I was using RavenDB around 2015-2016 timeframe. It's been a _long_ time since then. That was my opinion back then. My experience using RavenDB has been mostly for web applications. I remember reading [Ayende's blog a lot](https://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer) and he was a firm believer in no repository or Unit of Work pattern.

Thanks for the comment!