locked
MVC or Webforms ? Datareaders or Linq-to-EF ? RRS feed

  • Question

  • User923120180 posted

    Hello,

    Hope everyone's doing great. I am involved in a migration project from VB6 and trying to decide between MVC or Webforms for the new architecture. No matter which I would choose I would use a layered architecture approach, with Service, Model, Repository and Infrastructure Layers.  But I was wondering which one would tend to be more responsive, MVC or Webforms ? One of the customer's requirements is that they want near instantaneous responses to data requests.

    I would be using Linq and Linq-to-EF in both cases for data retrieval. The second part of my question is would ADO.net DataReaders and DataAdapters be faster than Linq ?

    Thanks

    Wednesday, June 24, 2015 2:22 PM

Answers

  • User281315223 posted

    But I was wondering which one would tend to be more responsive, MVC or Webforms ? One of the customer's requirements is that they want near instantaneous responses to data requests.

    It's really going to be a matter of what you are more familiar with. Both of these technologies can be as fast as you would like if they are properly designed, however if you don't know the best approach to implement certain things, you could run into issues, so I would encourage you to go with the one that you know best.

    With that being said, in my opinion, ASP.NET MVC is quite a bit "leaner" than Web Forms and I believe that it can make things quite a bit easier to separate all of the concerns / components within your application (as it is inherently already broken up into three major components : the model, the view, and the controllers). 

    I would be using Linq and Linq-to-EF in both cases for data retrieval. The second part of my question is would ADO.net DataReaders and DataAdapters be faster than Linq ?

    With regards to "instantaneous requests", this is going to require quite a bit of tinkering to determine the best and fastest approach to accessing data (depending on the type of data that you are dealing with). The use of an ORM like Entity Framework or a bare bones ADO.NET approach (e.g. datareaders) is one of those common discussions with each side thinking that there approach is "best".

    The truth is that Entity Framework is going to basically generate SQL that will be extremely close to the performance you can get with writing the SQL yourself (in the most basic of cases), however if you are dealing with complex joins and other types of logic, you'll likely want to write the query yourself as Entity Framework is probably going to be giving you quite a bit more than you want back. Queries with LINQ are syntactically a bit easier to write if you aren't terribly familiar with SQL, however if you are then there is no reason that a simple ADO.NET connection wouldn't work just fine.

    A few keys to remember to keep your database requests fast : 

    • Ensure fields that are going to be queried or accessed frequently are properly indexed.
    • Only pull as much data as you need for a single request; Consider implementing paging if you are going to be "paging" through large quantities of records as opposed to pulling the entire dataset at once.
    • On a related note, only pull what you need in each request (e.g. avoid things like SELECT * FROM YourTable and instead use SELECT PropertyA, PropertyB FROM YourTable)
    • If you have common joins that you are performing, you might consider making a SQL View to query from, which will function as an impromptu table and can sometimes speed up your queries.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 24, 2015 2:51 PM

All replies

  • User281315223 posted

    But I was wondering which one would tend to be more responsive, MVC or Webforms ? One of the customer's requirements is that they want near instantaneous responses to data requests.

    It's really going to be a matter of what you are more familiar with. Both of these technologies can be as fast as you would like if they are properly designed, however if you don't know the best approach to implement certain things, you could run into issues, so I would encourage you to go with the one that you know best.

    With that being said, in my opinion, ASP.NET MVC is quite a bit "leaner" than Web Forms and I believe that it can make things quite a bit easier to separate all of the concerns / components within your application (as it is inherently already broken up into three major components : the model, the view, and the controllers). 

    I would be using Linq and Linq-to-EF in both cases for data retrieval. The second part of my question is would ADO.net DataReaders and DataAdapters be faster than Linq ?

    With regards to "instantaneous requests", this is going to require quite a bit of tinkering to determine the best and fastest approach to accessing data (depending on the type of data that you are dealing with). The use of an ORM like Entity Framework or a bare bones ADO.NET approach (e.g. datareaders) is one of those common discussions with each side thinking that there approach is "best".

    The truth is that Entity Framework is going to basically generate SQL that will be extremely close to the performance you can get with writing the SQL yourself (in the most basic of cases), however if you are dealing with complex joins and other types of logic, you'll likely want to write the query yourself as Entity Framework is probably going to be giving you quite a bit more than you want back. Queries with LINQ are syntactically a bit easier to write if you aren't terribly familiar with SQL, however if you are then there is no reason that a simple ADO.NET connection wouldn't work just fine.

    A few keys to remember to keep your database requests fast : 

    • Ensure fields that are going to be queried or accessed frequently are properly indexed.
    • Only pull as much data as you need for a single request; Consider implementing paging if you are going to be "paging" through large quantities of records as opposed to pulling the entire dataset at once.
    • On a related note, only pull what you need in each request (e.g. avoid things like SELECT * FROM YourTable and instead use SELECT PropertyA, PropertyB FROM YourTable)
    • If you have common joins that you are performing, you might consider making a SQL View to query from, which will function as an impromptu table and can sometimes speed up your queries.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 24, 2015 2:51 PM
  • User923120180 posted

    Thank you Rion for your valuable feedback.

    - Darius

    Wednesday, June 24, 2015 3:13 PM