At the moment I have a fairly big website with about 10k visitors a day.
This is a community website with news/blogs/videos and a big forum.
This all runs on a self made PHP5 application which performance faily well, has good performance. The database is a MySQL5.1 database.
Now I am getting fedup with PHP and the loose typed framework, lack of namespacing and a proper MVC setup, so I am thinking of rewriting the site in MVC3 ASP.NET.
Now I have experience with this, but not in the MVC framework yet, and I have a few questions about the performance, especially the Entity Framework:
Is it even worth using the entity framework? Will it cost alot of overhead and performance degration? I am not sure yet if I should switch to MSSQL.
Entity Framework was not performance optimized as far as i have worked with it. That is not it's primary goal by design. Performance is important of course, but EF is at most easy to use, and start with. It provides an fast way integrate with existing database, or create database really, really fast. Performance is not the primary goal, but improving indeed.
Here is an good chart with some benchmarks from the Microsoft team, that can be a ground for making the decision.
As you can see, there is a dramatic performance improvement from .NET 4.0 to 4.5 as far as it comes to "LINQ to Entities". It still seems twice slower than direct SQL though. LINQ to SQL is the slowest operation of course.
ASP.NET MVC is an good direction, especially if you want to try something different. EF is not the best you can do if you pursue performance. Writing the business layer on your own, including the SQL stored procedures would be better, but will require a lot more time.
When using an ORM like EF or NHibernate you always have to live with the trade-off between performance and convenience. If you can live with a relatively bad performance (I think it should be possible to run your site w/ an ORM) NHibernate should your first choice, from my point of view it is more mature while EF is still lacking provider support and has some shortcomings with respect to the develevopment workflow (which you possibly expect when using NHibernate but not when using a MS tool).
If you switch from PHP to .NET you should consider switching from MySQL to MSSQL, just because it fits perfectly into the MS ecosystem (and performance/scalability should be improved too, this could possibly outweight the performance degradation you expierence when using an ERM).
You could also take a look at LINQ which could be an alternative between a classic ORM and hard coded SQL commands (also with respect to the performance, LINQ to SQL is pretty fast and you can also use LINQ to Entitiy Framework when using EF (thats pretty slow)). LINQ would fit your needs if you want some level of abstraction wihtout the need of endless configuration and if you like RAD (who doesn't?).
In general the performance of ASP.NET MVC3 is quite good, but you should know that you need some experience to tweak your application and avoid (common) pitfalls. Cutting a long story short: You should be easily able to write an ASP.NET application that has a better performance than a scripted PHP page (by design)
But you should also know, if you decide to commit yourself to the MS ecosystem (.NET, MSSQL w/ LINQ/EF) its hard to break out and providers for LINQ and EF for non-MS RDBMS might cost some bucks (check www.devart.com).
Hope this gives you some guidance
Further reading:
ORM wars: Comparing nHibernate, LINQ To SQL & the Entity Framework
NHibernate vs Entity Framework: a performance test
NHibernate vs. Entity Framework 4.0
This is way too much of a general question, and there's no good answer to it. I highly recommend that you perform some tests using the Entity Framework as well as MVC3 and see that it meets your needs.
Also, and not to be condescending, but 10K visitors a day is not that much compared to other sites out there that are succesfully running ASP.NET MVC and Entity Framework.
In the end, I'd say it most definitely will meet your needs, but as with any project that scales, you will have to be aware of bottlenecks in your particular app and come up with solutions to address those bottlenecks.
This is 100% dependent on the queries.
I've worked on sites with 22 million a month with Nhibernate and about 10 million a month with Linq to Sql.
The queries that performed the slowest were always those weird aggregate quintuple join monsters. ORMs get you 95% of the way there. The rest you'll have to optimize. No ORM gets SELECT * FROM table wrong. Its the outliers that matter.
This will probably get closed as subjective/argumentative in the next five minutes, but I'll give it a shot:
You'll hear a lot of differing views regarding EF and other ORMs, but my personal view is that they cause more problems than they solve. Queries should be kept in the database, where they belong. Proper separation of concerns (SQL code in the database, app code in the project) saves you a lot of problems long-term.
Think of it this way: if your queries were all in stored procedures, you wouldn't even be thinking about migrating/rewriting them at this stage. You could focus on implementing the web side of your app instead of worrying about how to transition your SQL code.
So, skip EF for now, focus on what you know.
Related
After posting a question earlier, I started to wonder if an Entity Framework model (connecting to multiple databases) could run in a web garden with multiple worker processes? Has anyone attempted this?
Absolutely it can, due to EF's Unit of Work pattern it can work remarkably well in a web garden, it's not the ORM itself though that is a significant factor, it's the style and structure of the business logic that will make the difference.
One might even go so far as to say that EF is better suited for this than some other frameworks, but that is highly subjective, so we wont go there...
Unit of Work patterns work really well for REST style or stateless service implementations, if the state is not persisted between requests or across sessions then it is really easy to scale out the service implementation regardless of the framework that you are using to access the database.
That's not to say that a repository pattern can't be effective across a distributed hosting environment, personally I just find that with EF there is less boilerplate code and less effort to get the job done.
EF had a slow start, but it has matured into a very stable product, EF.Core looks to be heading in the right direction too ;)
While writing MVC views I see a lot of call to Html helper method such as EditorFor/LabelFor. These extensions use a lot of reflection behind the scenes. Coupled with how routing, model binding, validation, EF manipulation ... are all handled via reflection, I wonder how much it hurts performance?
I want to know what MVC framework does under the hood to tackle the implications of using reflection on such a large scale.
I'm sure it must be doing some kind of caching, but knowing what it exactly does will be a good learning experience and assurance that we are not compromising huge performance for the sake of some productivity gain.
As marc_s said in the comment using reflection is not necessarily a bad thing. I'm responsible for a lot of the performance investigations for MVC (and I even wrote a few blog posts on MVC performance) and the biggest perf issue in real world applications is database access. Everything else pales in comparison.
But we do try to keep the core framework as lean as possible and so we do caching where appropriate. This includes view file lookups, model lambda expressions and a whole lot more. The easiest way to learn about this would probably be to look at the source code and find places where we use Dictionary<Type, T>, MemoryCache, or HttpContext.Cache.
Another way would be to actually run an Mvc application under a profiler, but that's a bit more advanced topic (though if you search for it you'll get some good hits).
In the end you have to trust us that we are doing the right thing :) We have already optimized a lot of the perf issues and the remaining reflection usage just does not have that much of an impact.
And here's a greate video from Steven Smith on tuning the performance of an MVC application: http://channel9.msdn.com/Series/mvcConf/mvcConf-2-Steven-Smith-Improving-ASPNET-MVC-Application-Performance
The question is in the title.
It doesn't favor one over the other at all. It's just common to use LINQ to SQL examples because they are simpler to setup and deploy, so it's easier to digest the sample code without getting distracted by something which deserves its own learning path.
I agree that it does not favor one over the other. I always assumed that Linq to SQL tended to be used in examples because it was released about a year earlier. Therefore, book writers were more familiar with Linq to SQL and/or felt it was more stable.
I agree with Rex in that it makes more sense, when giving a tutorial about ASP.NET MVC, to keep other technology decisions simple. Since either DAL implementation can be used, it is easiest to teach MVC by using Linq to SQL (the simpler of the two). Linq to SQL is also widely considered to be more light-weight.
I must admit, it would be nice to have more open-source examples of projects using ASP.NET MVC along with Entity Framework. I can tell you that it works fine, because I am using it on one project. However, it can be a bit more difficult to figure out some of the ideosyncrasies. Here is another question that shows some links to examples.
I think this tendency to use the path of least resistance in example is a diservice to new developers. How many times have you seen an example, with the caveat that it is not production worthy code, with no reason as to why it is not appropriate, or good direction on how to find what is best? Personally, I appreciate longer examples that actually lead me to discover how something should be used are more helpful.
In this particular case, using Linq to Entities would be much more useful, as it is seemingly the future.
In my opinion, it doesn't favor it. It's what you see in most examples, because Linq to Sql is the fastest way to get examples up and running. Rails follows the same convention of many examples using features (scaffolding for example) that you would rarely see used in a production site.
As all the other posters have said - L2S samples are just a lot easier to put together hence you'll see them quoted more. In reality your MVC models may not use L2S directly - they could be hooking up to a separate services tier or some data transfer objects exposed by another system entirely.
I am starting a new ASP.Net MVC project and was wondering what is the best Model approach to take.
Most demos recommend LinqToSQL but I know Microsoft are not really enhancing this product and are focusing more on the Entity Framework.
I like the Subsonic approach but I thought this was going to be built in with MVC with version 3 but there has been no news about the development stage of this project so I am a bit wary of using version 2 if there is to be a new release soon.
I have heard of NHibernate and Castle Record but have not had any experience at all with these and have heard numerous pros/cons for both.
Any help would be highly recommended!
nHibernate learning curve is higher but worth it. Use Fluent nHibernate to ease the pain a bit. nHibernate is less visual that some ORMs but that is really only an issue when you are beginning and once you have experience with it the lack of visual designer is a benefit IMO.
For SubSonic, Rob just release an new MVC template which you can use when starting a new project that bakes a lot of good stuff into a new MVC project including a pre-release of SubSonic 3. Detais are available on Rob Conery's blog.
LLBLGenPro works great for me. It is the best .net ORM out there. I'd avoid Linq to Sql because you'll have problems once the project grows and it is rather weak in features (besides the obvious downsides, like works only with SQL Server, etc.)
I use linq2sql and I think it works absolutely great if you use MSSQL as your database (it works on other databases too, but it requires some 3rd party tools). Yes, Microsoft has 'discontinued' its development, but it is mature enough for the average project. I doubt you will run into any walls. If you're starting a big project that you need to support for years to come, then the Entity Framework might be more suitable.
I personally haven't used NHibernate and Subsonic before, but like Craig says, the learning curve of NHibernate is a bit more steep, though it is supposed to be a great framework (everything from what I heard or read).
If you're willing to spend some money or have a smaller project I'd at least try out LightSpeed. I found pain points withe very ORM I've ever tried and I'm currently using LINQ to SQL myself.
LightSpeed is pretty feature rich though the LINQ support is missing a few features nothing major that can't be worked around. It's pretty close to being the same as LINQ to SQL and LINQ to Entities but has a few more features like Full-text Search.
Castle ActiveRecord works really well for small-to-medium projects based on MVC - I'm using it on a couple of projects at the moment and finding it a very good fit with ASP.NET MVC.
It's an implementation of the active record pattern that uses NHibernate under the hood - in other words, as long as you're happy having one class per database table, it'll do most of the NHibernate configuration for you, leaving you free to write code like:
Customer bob = Customer.Find(/* customer Id goes here */);
bob.FirstName = "Robert";
bob.Save();
Invoice newInvoice = new Invoice();
newInvoice.Products.Add(Product.Find(/* product ID goes here */);
bob.Invoices.Add(newInvoice);
bob.Save();
with very little explicit NHibernate configuration (assuming you have Customer, Invoice and Product tables in your DB, of course)
Because it's NHibernate under the hood, migrating to NHibernate if you need to should be straightforward - you'll already have all the necessary references and libraries. There are a few aspects of NHibernate behaviour that you can't ignore (like session scopes and flushing) - but it's not too hard to work out what's going on with these, and using them in ActiveRecord will give you a head start if/when you need to move to using NHibernate directly.
We're using Fluent + NHibernate here, it works pretty well. Some alternatives that mesh well are SubSonic, Entity Framework, and Linq to SQL. I think straight NHibernate is a bit more cumbersome than it is worth, but is a great underlying layer with Castle ActiveRecord, and with Fluent.
I worked with a product called netTiers (http://www.nettiers.com/) on a project and that worked very well. It's a CodeSmith script that generates business objects from your database tables, views and stored procedures.
If it's not a huge project, I'd use Linq To SQL. If you need all the bells and whistles, bone up on nHibernate and have at it. I don't think you'd run in to any serious issues one way or the other.
I've been learning ASP.NET MVC for about a month now and I'm certainly sold on its benefits but I realize it is not applicable to all situations.
I've read in several places that ASP.NET MVC is not ideal for data-intensive applications:
Example 1: "Data Driven Application – life would be MUCH easier using WebForms if the application is data heavy"
Example 2: Nick Berardi's book suggests that you side with Web forms if your application is "data-heavy"
Can someone clarify as to why ASP.NET MVC is ill-suited towards data-heavy applications and why Web forms are more appropriate? Also, where does one draw the line between data-heavy applications and other applications? Are we talking quantity of data (millions of records) or are we talking large data models?
I would really like this clarified as well, as I have found the exact opposite to be true, and I think stackoverflow.com is evidence of the suitability of MVC to data-driven apps.
I didn't bother reading much of the second link, but the assertions in the first are not qualified, and many of them seem wrong to me. The stated weaknesses of WebForms, though, would be enough to drive me from using it for a data-intensive app:
UI logic coupled with the code, and thus is hard to separate.
Harder to unit test, so difficult to employ TDD.
Heavy page sizes due to view state management.
The stated weaknesses of MVC are quite flimsy:
Not event driven, so maybe difficult for people who know only Asp.Net Webforms to wrap their minds around it.
Third party control library support is not that strong.
No ViewState(this is also a strength).
The first one can be seen as a plus as much as minus. The second is just wrong as MVC apps can leverage traditional server-side controls if they wish, as well as make use of the rich library of client-side controls and libraries. The third, well I don't think I even need to speak to that one...
You have to be wary when reading articles like this on the internet - they sound authoritative and comprehensive, but where is the meat? Why are the stated weaknesses an issue? It is not enough to just throw opinion out there as fact. They should be backed up with metrics, such as when using platform x over y, developers unfamiliar with either platform were able to complete an application 30% faster, or platform x resulted in 25% fewer lines of code, or fewer levels of indirection, or whatever.
The idea that RAD is a plus is another one that bears careful examination: RAD is fast until you want to do something a particular control was not designed for, and then you hit a brick wall. It is a leaky abstraction and when it fails, you are suddenly confronted with the full complexity of understanding the design framework and code of the given control. This can be quite a setback, and the source code for these controls is not always available.
Doesn't make much sense to me. They might be speculating on the difficulty of creating many models if you have lots of different types of data, or perhaps the relative difficulty of creating web forms in MVC.
However, ORMs (such as L2Sql, EF and Subsonic), model binders, and form generators (I can't find the link right now) pretty much hose those arguments.
Frankly I don't buy it.
I believe that these authors are talking about the ability to drag/drop data controls onto the page such as GridViews, FormViews, and other databound objects.
Say you have a database for your IT department, with a table for computers, a table for printers, one for software, etc. The UI for this is a very simple data management system, essentially a glorified MS Access.
Rather than writing an elegant web app, with beautiful HTML and a class library, you could simply create a quick/dirty WebForms app by dragging your data sources and controls onto the page in Visual Studio.