Datacontext/UnitOfWork

[NickBuckland]

I am new to MongoDB and am trying to get a grip on best practice..
In that past I would have created a Repository, a DataContext maybe a UnitofWork. At first when I looked at your code I thought the DataContext /UnitOfWork abstraction was missing, but thinking about it, the UnitOfWork can be encapsulated by instantiating a repository and performing some action on it. My question would be around latency in creating a connection to MongoDB every time you create a repository. Is there a heavy burden? Do you have any opinion around UnitOfWork etc?

[tegeek]

I think the best regarding connection to db in MongoDB world is you keep your connection opened during the life of application. MongoDB driver handles the connection internally so even if you open 100s it'll keep a pool of fixed connections and return you the same. Also if you keep your connection open, the driver will immediately warn you when one server goes off and will then shifts to you next secondary server.

Since MongoDB doesn't support transactions, so the UnitOfWork pattern has of no use.

[NickBuckland]

That's my point, the MongoRepository constructors take a connection string as a parameter, so I have assumed that a new connection is made every time a MongoRepository is created so...
void DoStuff(){
var repo = new MongoRepository();
repo.Add(newitem);
};

would create a new connection each time the method was invoked.
Can't a Datcontext contain the connection?

Ok about UnitOfWork, I did not know that transactions where not supported.

[RobThree]

would create a new connection each time the method was invoked.

It doesn't; MongoDB's C# driver (which we use) handles this internally and simply uses a connectionpool.

This class serves as the root object for working with a MongoDB server. The connections to the server are handled automatically behind the scenes (a connection pool is used to increase efficiency).

I did not know that transactions where not supported

From https://docs.mongodb.org/v3.0/core/write-operations-atomicity/ :

In MongoDB, a write operation is atomic on the level of a single document, even if the operation modifies multiple embedded documents within a single document.

And https://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/ :

Because only single-document operations are atomic with MongoDB, two-phase commits can only offer transaction-like semantics. It is possible for applications to return intermediate data at intermediate points during the two-phase commit or rollback.

In my experience, most likely when you're in need of transactions you're probably using MongoDB as an RDBMS and trying to fit a square peg in a round hole ;)

[NickBuckland]

Thanks Rob that helps. As I stated at the beginning I am trying to grasp how the architecture or my thinking needs to change in order to get the best from NoSQL as opposed to a more conventional BLL/DAL with repository or ORM implementation