Native and cross-platform MongoDB manager
Whatever platform you use today — Robomongo is available for you. Distributed as a native application, fast and snappy Robomongo uses very little of your machine resources.



Using MongoDB .NET Driver with .NET Core WebAPI

Petru Faurescu. CodeProject. 2016-11-02.
How to build step by step an ASP.NET Core WebAPI with latest MongoDB driver. The project supports all requests to MongoDB asynchronously. This is first part of building an Angular Notebook WebApp, presenting the backend.

[Using MongoDB .NET Driver with .NET Core WebAPI]

How To Be MEAN: Robust Validation with MongooseJS

Ted Neward. MSDN Magazine. 2016-03-01.
In my February 2016 column (, I transitioned to a MongoDB database. Doing so wasn’t that hard thanks to the JSON-based nature of Node.js and the JSON-based nature of MongoDB. (Life is always easier when working with data if the transition is from apples to apples). MongoDB has a great advantage in that it will “scale up” and “scale out” easily, not to mention that it’s trivial to get started. But it also has a significant drawback: Because MongoDB is a “schemaless” database (in that the schema is already predefined—a database holds collections, collections hold documents and documents basically are just JSON objects), within it lies the seeds of its own destruction.
First, recall that MongoDB queries are essentially query documents (that first parameter to the find call), containing the fields by which to scan the collection for matches. So if the query “{‘fristName’: ‘Ted’}” gets executed against the “persons” collection in the existing database, nothing will come back—the field name in the query document is misspelled (“fristName” instead of “firstName”), so it will match against no documents in the collection. (Unless there’s a typo in the document in the collection, of course.) This is one of the biggest disadvantages of a schemaless database—a simple typo in the code or user input can create accidental bugs of the most furious head-scratching nature. This is where it would be nice to get some language support, whether that’s by a compiler or an interpreter.
Second, notice that the code displayed in my last column is reminiscent of the “two-tier” applications that were popular for two decades during the “client-server” era of computing. There’s a code layer that takes input directly from the user (or, in this case, from the API consumer), applies it and gets a simple data structure back from the database, which it hands directly back to the caller. There’s certainly no sense of “object-orientation” in that code. While not a deal-breaker, it would be nice if we could get a stronger sense of “object-ness” to the server-side code, such that some validation of various properties could be centralized in one place, for example. Case in point: Is it legal for a person to have an empty firstName or lastName? Can he be doing absolutely anything in his status? Is there a “default” status, if he chooses not to provide one, or is an empty status acceptable?
The Node.js crowd has wrestled with these problems for quite a while (it was one of the first language ecosystems to adopt MongoDB on a large-scale basis) and, not surprisingly, it has come up with an elegant solution to the problem, called MongooseJS. It’s a software layer that sits “on top” of MongoDB and provides not only a schema-like language-verified validation layer, but also an opportunity to build a layer of “domain object” into the server-side code. Hence, it’s sort of “the other ‘M’” in the MEAN stack.

[How To Be MEAN: Robust Validation with MongooseJS]