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.
Related
I am working on a new project which is to use Asp.net MVC 5 and Cassandra.
I am very OK working with entity framework.
Is there a way of connecting entity framework to a Cassandra database?
If not, can anyone help me with the necessary structures to have my MVC 5 application work with a Cassandra database?
More especially is the fact that i want to work with the MVC 5 identity.
I'll really appreciate any help.
All the old versions of EF, up to version 6.x, don't support NoSQL databases like Cassandra.
EF7 is still under development, but it's being designed to be flexible enough to support NoSQL databases. As of today, (Nov 2015) there isn't still any support for a NoSQL database in the current EF7 beta8. But we can expect to see it in the future.
For example you can see it mentioned in this article of MSDN magazine: Looking ahed to Entity Framework 7:
Beyond Relational
When Entity Framework was first introduced, Microsoft had a vision of it being used for a variety of data stores, though the first pass focused on relational databases. Non-relational databases existed at that time, but were not widely used, unlike the NoSQL databases—especially document databases—that are so popular today.
While EF is an Object Relational Mapper (ORM), developers who use it want to be able to use the same constructs to interact with non-relational databases. EF7 will provide a high level of support for this, but keep in mind what high level really means. There are vast differences between relational databases and non-relational databases and EF will not make any attempt to mask those differences. But for basic querying and updates, you’ll be able to use the patterns with which you’re already familiar.
I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/
Is Database class just a wrapper for ADO.NET which makes use of db simpler ? What's its limits ?
Yes - the Database Helper is a wrapper around ADO.NET. It is designed to minimize the code that a beginner needs to get started with querying databases, similar to how its done in PHP. Its limits depend on your point of view. As someone who is just starting to learn web development and databases, you might think that the helper is a stroke of genius. As a professional developer, you might not like the fact that it returns dynamic types or that it doesn't prevent people dynamically constructing their SQL and potentially opening up their application to SQL injection attacks.
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.