I'm designing a backend app using a GraphQL, MongoDB, .Net Core stack where performance must be excellent. Wondering if given that the .net core Mongo driver supports Linq if we could just skip using a Mongoose or EFCore middle layer and just use a Repository pattern on top of the DB layer?
We're normally an EF shop so familiarity is a plus but it carries so much baggage and this app schema is fairly simple. 80% of our DB will be "sql-like" and only 20% actually requires NoSql, but due to cloud hosting costs we're going with Mongo for everything. Mongoose was suggested to me, but I'm not really seeing what I gain there.
Has anyone used this combo? Any suggestions appreciated!
Mongoose is different stack all together and there I am guessing you basically plan to use a another model to provide abstraction over the top of data that is being stored in the database.
https://docs.mongodb.com/realm/graphql/ => Check this out if GraphQL is what you are specifically looking for, without any big layer change.
One added layer in between your let's say .NET backend and an extra layer would extra hop BTW. (If you use another tech to just act as abstraction layer)
Related
Microsoft provides two ways of working with cosmos dbs in C#/.NET.
One can either use Entity Framework(EF) Core, which makes use of the cosmos SDK behind the scenes and allows you to use EF with Cosmos.
This last point could be seen as positive or negative depending on if you want to use EF vs Dapper or whatever, but for my use case, I would prefer to use EF unless given a good reason not to.
Microsoft themselves has not made any statement I can find on which should be used or why. (I Assume this is a .NET Core project)
EF Core works only for SQL API of Cosmos DB as of now. So, If you are using other APIs, you cannot use EF Core.
Also, Take a look at other limitations of EF Core Azure Cosmos DB Provider Limitations at https://learn.microsoft.com/en-us/ef/core/providers/cosmos/limitations
We used Cosmos DB SDK which is quite flexible and the performance is also good.
After an experience with Cosmonaut package, EF Core and SDK I have to say that Ef Core is focused on relational mapping. Witch Document DB you need to focus on Json serialization. Ef Core model configuration feels cumbersome and limiting for document DB interaction - You have to configure things that just works while serializing. Both Cosmonaut and SDK allow focusing on serialization which in most cases just works. Cosmonaut is a convenient facade on top of SDK - but looks dead at the moment so I recommend SDK.
I'm building a server application that interfaces the world via a RESTful web service and uses MongoDB of storage. As it happens, the JSON resources of the web service are fairly close to the structure of the BSON documents stored in Mongo.
While I typically use an object-oriented DAO abstraction to hide the details of persistence implementation, it doesn't quite seem to be the best fit in this case since what I really want to do is fetch a document from the DB based on a query and perform a transformation. Building an object graph as an intermediary seems excessive.
Does anyone have any recommendations for an abstraction pattern that fits this bill?
Edit: Removed 1AM degression about just not using any abstraction and just using the Mongo driver directly.
The level of abstraction is up to you, your needs and your requirements. There are various language specific layers on top of the native MongoDB drivers. It is up to you decide what you need and not to us. We can not give recommendation without more precise and detailed background. If you ask a generic question then you will receive a generic question.
And who gave this +1? For what?
I'm interested in using an object relational mapper for an existing system which is a ASP.NET client, ASP.NET Web Services middle layer, and with an Oracle back-end. All database access is done using stored procedures and no SQL is allowed in the web services. I've been investigating NHibernate, Telerik's OpenAccess ORM, and the Entity Framework. I titled this "segregated" because the database is pretty tightly controlled by the DBA's. They also control the database design and reworking the database for adequate normalization (for the object model) is pretty much out of the question. Also, allowing the tool to create any of the SQL is also out the question.
My question is: Given these constraints, which of these tools would allow the best integration for this sort of environment?
None at all.
You're not going to be using 99% of the functionality of an ORM by having everythign done in Stored Procedures.
Probably better to use a Micro ORM like ServiceStack.OrmLite, or Massive, etc...
But looking at any full fledge ORM like NH, LightSpeed, EF, is complete over-kill and will just create more complexity for 0 gain.
Implementing your data access with stored procedures entirely does not mean that you won't gain any value by using an ORM. It just means that you will probably not use some of its benefits.
As for the ORMs you have evaluated, you have probably noticed already that:
All of them support Database First approach, where you can just create your model after the database is already defined, so you won't have to interfere with the DBAs work in any way but to ask for credentials
Entity Framework and OpenAccess provide visual representation of your model out of the box, while NHibernate doesn't
OpenAccess and NHibernate support Oracle, while with Entity Framework using Oracle is not so straight forward
The stored procedures support in Entity Framework and OpenAccess is much more sophisticated than in NHibernate. In OpenAccess you can even map a stored procedure to more than one results set.
I hope that helps.
Let me get this right. Your constraints are:
You have to use an ORM
You cannot modify the database in any way.
You can only use stored procedures.
I think I agree with #Phill. A full blown ORM is overkill when you cannot use it's functionality.
BTW, I once worked on a system like this where the DBA's ruled the roost and mandated only procedures to access the data. Nightmare.
I'm looking for a common data access framework that will provide portability across various nosql databases like SimpleDB, Azure Tables, Cassandra, CouchDB, MongoDb, etc. I'm building an app and would like my customers to be able to use which ever nosql store they want.
In a more relational scenario, I'd use Linq over nHibernate or Entity Framework, but I haven't found an equivalent framework for nosql databases. All I've found is database specific API's even though there seem to be significant commonality. Does one exist? Preferably one with LINQ.
No these things are too different and too specific (at least right now). If you wanted something really simple, like just a wrapper on an object that is only accessed by ID, then you may have a hope. In fact, if you look at NoRM, it may be possible to adapt that to various providers.
However, outside of a small core set of features, these "NoSQL" databases are quite different in many regards. I mean, how do you implement the various map/reduce functions agnostically? How do you implement atomic operations when they support different atomic operations?
Either way, we're way too early in the NoSQL life-cycle to have an agnostic framework for all of this. Azure basically dropped their NoSQL offering in favor of "hosted SQL server". MongoDB is maybe 20 months old, CouchDB is still on version 0.11.x, SimpleDB is less than 24 months old, Cassandra is on version 0.6.2 and has maybe been in regular use for a couple of years.
We're just not there yet.
A common query language (called UnQL) is being developed: http://www.unqlspec.org/display/UnQL/Home
There are LINQ providers for MongoDB but I don't think that there is a generic .net linq provider to 'all' nosql db's .
Some people have contemplated about a generic nosql query language: http://nosql.mypopescu.com/post/731261002/a-common-nosql-query-language
If you only have basic persistence persistence requirements, I maintain a common caching API with providers for Memcached, Redis, InMemory and FileSystem caching.
It only supports Redis, but I have a C# Redis Client that has a very familiar C# API. It natively supports persisting POCO types and exposes all of Redis's advanced server-side data-structures as native .NET IList, ICollection data structures so they can easily be used in existing C# APIs like LINQ, etc.
We have a complex architecture with much logic in unmanaged code that needs database access.
Currently this is via ODBC drivers and MFC classes and we're considering the issues of migrating our abstraction layer to use ADO or ADO.Net. In the latter case we'd have to be pushing database logic back up into the .Net layer. I'm trying to decide if the pain of invoking the database via .Net callbacks is offset by the improvements in ADO.Net.
The Wikipedia comparison was interesting although I'm not sure I believe all the points in the comparison table (eg: does ADO.Net always use XML to pass data?).
A 2005 comparison shows ADO.Net performing dramatically faster.
Microsoft's guide to ADO.Net for ADO programmers suggests we will gain much from going to ADO.Net especially the way that data is available in native (.Net) types rather than solely through OLEAutomation's Variant.
eg: does ADO.Net always use XML to pass data?
No. Sounds like idiot information in wikipedia then.
2 choices. First, I would REALLY get rid of ODBC - and move at least to OleDb driver wise. If possible (tell me - I have a .NET app using an ODBC driver to call a JDBC ddriver to call a third party application server).
Now, you can go both ways - ADO on both sides, managed ADO.NET and expose from the NET layer - but this is really not a programmer decision, it is an architectural thing that should be seen in the major context.
I would possibly go for a .NET layer, possibly with at the same time an OData exposure layer, and try to consume that from the unmanaged layer.