Migration to .NET Core / .NET Standard about mongorepository

[agatlin]

@cphillips83 I know exactly what you mean . I have used EF since its very humble beginnings and currently use EF Core. I feel am constantly banging my head up against a wall trying to work around its limitations. Now, in EF Core, they have removed some much needed functionality, and I am still uncertain when it will return. This makes it even more of a pain. I often use Dapper for performance-critical repositories, but even this is a bit of a chore.

My current project has a need for multi-level hierarchical data of varying types. For this reason, I have been diving into MongoDb and Redis and am still trying to work out whether it makes more sense to write a repository wrapper + utility functions around Redis or MongoDB. (I did look at RavenDB also but did not find it particularly appealing.)

I am having trouble gauging how many other .NET folks are using MongoDB now. Is there an active community? If not, what other document database frameworks are folks using?

[cphillips83]

I would like to note that I would gladly give ownership of MongoRepository2 to anyone else if it was something they wanted to maintain (not much to really do).

Our original intention was to use this at our company but we quickly realized the things we wanted to do were not "repository" friendly. Even our current design for our flagship product is a completely hand wrote entity system just because there were too many pitfalls with Entity Framework (this was over 3-4 years ago).

While I think these are great for learning, they are far too inflexible outside of anything other than simple CRUD. Too many times you simply need to get down and dirty and write custom queries for those edge cases.

Take this with a grain of salt as we don't have a lot of experience with the repository pattern outside of our hand rolled ones.

[tegeek]

@cphillips83 It is not unusual to use a number of different patterns in the same application, once the application grows a little bit. Repository pattern is an abstraction over Data Access layer. Like all other abstractions it also hides the under laying data source, hence you lose the power to run custom queries (for performance etc.) So you can use Repository while some parts of the application can by pass it. If after some time you realize that Repository isn't what you need because too many custom queries then you can abandon it completely.

Unlike EF, there is one ORM called ORM Light which is way better when you want to avoid Repository. ORM Light allows you to bundle entire DAL inside the business logic layer without going banana. (You can do the same with EF but its way more dirty).

[cphillips83]

@agatlin I wouldn't focus on a .NET community because that would be just centered around the MongoDB Driver for C#. The MongoDB community is pretty large and there are a lot of resourceful tools out there for it. I spend a lot of time just in the mongo db console looking at data and learning how to model my data which is the most crucial point.

The biggest point is to first model your data, I can't stress this enough. I didn't follow this advice and tried to do research with only a little thought in to how my data would be stored. I learned a lot of from storing log data, there was also a good article on storing metrics as well.

EDIT: Here is MongoDB's use case list with examples and was probably the most helpful to me.

I've spent most my life in SQL and would suggest making some quick dirty apps first just to achieve your goal and work backwards and see if a data wrapper works for you. When I went back and just wrote the code I needed to get the result I wanted, it was then I realized a repository pattern wasn't right for the app I needed.

@tegeek I agree, for me though its not that trivial. We have around 40-50 devs that have to work on an abstracted layer and their skill set range for "knowing queries" to "whats sql". We also follow a strict PR policy and have to enforce consistent rules on how the database is accessed.

I definitely didn't mean for any negativity towards this sort of tooling, it has great use cases. I will also check out ORM Light and see if it fits in anywhere for us.

[agatlin]

@cphillips83 "I've spent most my life in SQL." <-- This is so me. If we (my team) proceed down the Mongo path for this project, I might be interested to take over the management of the MongoRepository2.

At this point, I am still trying to get a handle on the various alternatives so I can make an architectural choice.

I have narrowed my choices down to three--all of which involving using a JSON document store for my (very) funky hierarchical data and a relational data store for all other data where it is more appropriate. In no particular order, my current options are:

1. Use MongoDB. It is relatively straightforward but is still brand new to me, and there are some tasks I am not yet sure how to best accomplish in this system (e.g. providing a unique ID to every object in the hierarchy--even if they are all part of the same document, easily adding/updating/deleting sections of the document, etc.)

2. Redis for storing JSON documents + Newtonsoft JSON for serialization (and LINQ to JSON for querying). Performance is blazingly fast but a bit more work. I am trying to figure out if using MongoDB really buys me anything I don't get with Redis and NewtonSoft JSON. (I could easily implement a repository library on top of these if is not one already.) (I would still use a relational data store for my relational data.)

3. SQL Server / Maria DB / Another Relational Store + NewtonSoftJSON--for JSON document storage AND the relational store also for the relational data. Both SQL Server and MariaDB allow for indexing and querying against JSON data. I am thinking maybe to write a generic wrapper/repository that could be used with both of these (and probably MySQL as well).

As of this moment, I have no idea which path I might take and feel a bit overwhelmed as I stand at the for in the road. I am pretty sure whichever path I choose will cause me to curse myself later.