we started a new ASP.NET MVC Project with EF and .Net 4.5. Original plan was to use code first to create the database, but that seemed a bit too complicated, probably mostly because all of us were familiar with DB-designs and it seemed just much easier and faster to do everything in SQL.
So for now we use EF to simply create mappers for our tables, views and functions. Stored Procedures don't really want to work for us automatically, so we are calling those manually with SqlCommand. Now a problem sometimes emerges with the complex connection string and all the XML-files which need to be referred in it. (At least which are referred when we use the automatically created connection string).
Long story short - EF has many features, of which we probably use only a hand full. We would be probably much happier with Linq2Sql. But that one is obsolete, and few months ago I read some scary posts, that when you want to launch your application in Azure, DB connections can break, and EF (from version 5 or 6) is so awesome and renews them automatically.
Is this true and EF the only usable ORM mapper for azure? Can we somehow deactivate all those features we don't use to have something as simple as Linq2Sql, should we use directly Linq2Sql even though it is obsolete, or just learn to deal with all those features? Or is the answer to use NHibernate (which seems to have a much more straight forward XML-configuration file, but no simple integration with Visual Studio to create all necessary classes)?
Update:
Another reason we gave up on code first and reverse engineered code first was, that we were missing an easy way to create wrapper functions for our SQL Server - stored functions. This feature is provided with the DB-first use of EF (as we use it)
Related
I am building a web api for my application and right now i am looking for ways to design my data access layer.
At the end, the application should be able to support a very large number of client and a very large number of queries.
I have heard about entity framework but i have two concerns with it:
I have been told by many that entity framework is not the best when it comes to performance, and performance is something that i can't afford to neglect.
I am only starting to build the application and i'm still looking for developers to join me, if i start with entity framework now, i might want/need to change an orm/library (because of the reason above or any other reason) or even a database technology in the future.
Repositories are a great way to abstract the data access layer and make it invisible to the business layer, so if one day i want to change the DAL/Database technology, i won't have to touch the business, only change the repositories.
Still, i have read a lot about how combining entity framework with the repository pattern is a bad practice.
I am really confused... and i have few questions.
Should i use entity framework? Performances is an important thing to me.
Should i combine it with repository pattern? If not, what do i do when i want to change the database technology/orm?
I have practice with using the repository pattern with native sql client (running native sql queries) but i don't have any practice with using orm's, at least not in .net
Is it really a bad thing for big application to use native sql queries and wrap them with repositories?
It is really important for me to begin writing my application in best way possible (applying all the best practices) so i won't have much struggle in the future.
Thanks,
Arik
Ad.1) Yes, Entity Framework is dead slow - BUT - when used out of the box, if the developers has deep knowledge of Entity Framework, what it does behind the scenes, how to optimize the queries - it can be as fast as your more low-lewel own implementation of data access.
Ad.2) If you want to change the ORM or the Database technology - that is not a matter whetever you use EF or not, it's a matter of the architecture you will design for the software.
Ad.1) see former Add.1, if performance is really important, I personally would go with low-level SqlDataReader, altough as I sad, it's possible to use EF in a performant way.
Ad.2) I don't see nothing bad in combining the repository pattern with EF, in small applications it may be an overhead, because the EF is basically an implementation of an repository pattern, so you would get a "double repository pattern", but it allows you to abstract away the coupling with EF
Ad.3) I don't think it's a bad way - but it depends obviously on the application.
I think that using a repository pattern is a good idea and a sort of wayout if you have some performance issues.
About Dapper the question is why Dapper is more performant than EF and NHibernate. No Lazy Load, no DML, easy mapper and so on. If you want DML (I do) and sometimes Lazy Load you could have a mixed approach. Repository Pattern + EF + Dapper.
My approach actually is Repository Pattern + EF + very few query (massive update and delete and few select - EF writes huge SQL statements also for simple queries - ). To map the select you can include Dapper (I don't), do it by hand (manually mapping or use the features inside EF - but there are some limitations - or write something generic). Usually I map it manually but I wrote also a mapper based on EF Mapping
Entity framework Code First - configure mapping for SqlQuery
I used it for few times and actually I don't use it anymore.
I've got a client who wants an ASP.NET MVC application. I'll develop it with VS.NET 2010 Express, demo it to him on my Linux server during its development (Mono supports ASP.NET MVC), and he'll eventually host it on a commercial provider running IIS.
Getting this done quickly is the name of the game. The only piece I'm missing here is the database layer. Ideally I'd use SQL CE and EF4. But SQL CE only works on Windows, and Mono doesn't support the Entity Framework anyway.
The only free Linq to SQL-like option I see is DbLinq. A quick test with that on a MySQL database had it erroring out on a table that had two foreign keys to a single primary key. A search on Google shows that this bug was identified, and a patch was created, two years ago or so. That the patch still hasn't been applied to the main source by now, and that this bug seems to affect so a common scenario, does not fill me with confidence on the production-readiness of DbLinq.
Even if it did work, it'd have to be with MySQL, as that's the only database I can expect to be available on both Linux and an eventual Windows server. (SQLite, Berkeley DB, etc., would all require some native drivers be installed on the server, which I can't count on.)
I don't know NHibernate. But from what I read, it requires manually creating XML mapping files... so I don't have to write SQL statements, but I do have to create mapping files? (Plus I'd need to learn how to use it.) Like I said above: Getting this done quickly is a goal here.
If I must, I will just pony up the $5 a month or so for a cheap ASP.NET hosting provider and use that to demo progress to the client, using SQL CE and EF4. But before I do that I'd just like to see if there are any other viable options. (It's kind of mostly an intellectual exercise by this point.)
So... any tips?
Does it really have to be a fully bloated ORM?
I recommend to have a look at some of the so called "micro-orm`s", especially my favourite one: Peta-Poco (http://www.toptensoftware.com/petapoco/)
Peta-Poco runs perfectly under mono and has an incredible performance. Even better, because of the small codesize (~1k lines of c#) it is very easy to understand what`s going on under the hood and you can easily change/extend the code to your needs. For the start you just have to copy the single .cs file in your project and you are ready to go.
Peta-Poco has a very well poco-mapping heuristic so you will get your c# objects out of the db with zero configuration for the most cases.
You COULD try Linq-to-SQL. Partially supported under Mono from 2.6, it supports many dbs under mono Release Notes Mono 2.6 (they are working with those of DbLINQ to make it).
Ah... Forget to learn quickly how to use nhibernate. It's very good but it's quite an hell. And creating the XML is the least (and with NHibernate 3.2 they have added their version of Fluent interfaces, so XML aren't anymore necessary I think. You can "code" your XML.)
I want to use NHibernate with Asp.net 3.5 but i don't know how to use it.I search on
Google but couldn't find the complete explanation about why to use NHibernate,Advantages of using it and integration with Asp.net projects.
I would suggest checking out Castle and NHibernate. I recently started using it and was blown away with what it can do. Castle manages all your sessions for you. Also it is easy to use LINQ with it.
Check out
http://davidhayden.com/blog/dave/archive/2008/04/28/NHibernateCastleActiveRecordTutorialUninitiated.aspx
Another great tool to use (Should work with ASP.Net) is the Nhibernate Profiler
http://nhprof.com/ It shows you what queries are being generated and the time its taking to run.
Also if you already have your database created you can download this tool http://www.agilityfororms.com/Home/Products/AfoCastleActiveRecordModelCodeGenerator/ It will create your models based on your database. Its works great for the most part. Although you have to register to download the free version still worth checking out.
Fluent NHibernate is supposed to be good as well although I have no experience with it. Might be worth checking out. http://fluentnhibernate.org/
You could have a look at this :
http://www.codegod.de/WebAppCodeGod/nhibernate-tutorial-1---and-aspnet-AID25.aspx
And this :
http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx
I'm nearing completion of my first project with it, and I've had mixed results. For basic data persistence, and assuming you already knew how to use it, it's much faster to build an application with it. You don't really have to worry about building stored procs and differentiating between new objects and updated objects.
On the other hand, until you're quite comfortable with it, it can take a long time to do something that would have been simple before. I've had a couple of problems, and it has been difficult and time consuming finding solutions to them.
To be fair, I've only written small applications with it and it has made the development process more difficult than I would consider required. The pain of using it is fairly similar from one app to the next, the benefits scale...
The best place to look is at NHibernate Forge. There's Blogs, wikis and groups that will help you out.
As for advantages of using it that is something you need to workout for yourself. Is it more advantageous than LinqToSql or Entity Framework? It depends on the project size and what you are actually looking for.
What I want to do is convert my whole application to nhibernate from ADO.NET and test it using different databases. i know nhibernate supports many different databases so can i switch between different databases without changing any of my application or nhibernate code?
As long as you do not write any specific queries targetted for a specific DMBS (which is possible using NHiberate (ISession.CreateSqlQuery), I would say that it is possible.
But, queries that have been written using hql or ICriteria API should work out of the box on other DBMS'es. (Provided that NHibernate supports those DBMS).
Although, it might be necessary to change some config settings (http://fgheysels.blogspot.com/2007/07/nhibernate-ms-access-problems-with.html for instance).
The short answer: yes. The long answer: It depends :-) I've done this numerous times, switching between SQLite (during early development and unit testing) and SQL Server (for later development, integration testing and production) with no code changes or recompilation - just Web.config changes.
If your application is fairly complex then you might run into some portability issues, but NHibernate is still a no-brainer if you want to support multiple RDBMS products for your application. Any such portability issues will usually be fairly straightforward to work around.
I am in the early stages of planning a conversion of a large classic ASP database application to ASP.Net and I'm having trouble picking out which data access method to use. I have played around with Linq To SQL, Dynamic Data, strongly typed datasets, Enterprise Library (Data Access Application Blocks), and a tiny bit with Entity Framework, but none of them have jumped out to me as "the one". There are just too many choices - my head is swimming, help me choose!
Perhaps it would help to give some background on the application that I am converting along with the priorities...
The back end is Microsoft SQL Server (2005 or later) and we are committed to that, so I don't need to worry about ever supporting a different database platform.
The database is very mature and contains a great deal of the business logic. It is highly normalized and makes extensive use of stored procedures, triggers, and views. I would rather not reinvent two wheels at the same time, so I'd like to make as few changes to the database as possible. So, I need to choose a data access method that is flexible enough to let me work around any quirks in the database.
The application has many data entry forms and extensive searching and reporting capabilities (reports are another beast which I will tackle later).
The application needs to be flexible enough to deal with minor changes to the database structure. The application (and database) may be installed at different sites where minor custom modifications are made to the database. Ideally the application could identify the database extensions and react appropriately. In other words, if I need to store an O/R mapping in the application, I need to be able to swap that out (or refresh it easily) when installing the application and database at a new site.
Rapid application development is critical. Since the database is already done and the user interface is going to closely match the existing application, I'm hoping to find something where we can crank this out fairly quickly. I am willing to sacrifice not using the absolute latest and greatest technology if it will save time in development. In other words, if there is a steep learning curve to using something like Entity Framework, I'm fine with going something like strongly typed Datasets and a custom DAL if it will speed up the process.
I am a total newbie to ASP.Net but am intimately familiar with Classic ASP, T-SQL and the old ADO (e.g. disconnected recordsets). If any of the data access methods is better suited for someone coming from my background, I might lean in that direction.
Thanks for any advice that you can offer!
Look at all three articles in this series:
High Performance Data Access Layer Architecture Part 1
Great advice.
You may want to look at decoupling the database layer from the asp layer so that you can not only give more flexbility in making the decision, but when you have to make changes to a customer's database you can just swap in a new dll without changing anything else.
By using dependency injection you can use xml to tell the framework which concrete class to use for an interface.
The advantage to doing this is that you can then go with one database approach, and if you later decide to change to another, then you can just change the dll and go on without making any changes to other layers.
Since you are more familiar with it why not just go directly to the database at the moment by making your own connections? Then you can move the rest of your code and along the way you can decide which of the myriad of technologies to use.
For a new application I am working on I am starting with LINQ to SQL for it, mainly because development will be quicker, but, later, if I decide that won't meet my needs I will just swap it out.
nHibernate might be a good fit. You can store the mapping in external configuration files which would solve your needs. Another option might be using ActiveRecord, which is based upon nHibernate.
nHibernate has a neat feature which you might find helpful. It's called a Dynamic property which is basically a name value pair collection populated by pulling the column names from the mapping file. So when you add a column at your client site, you update the mapping file and you'd be able to access the data through a collection on the object.