Using AJAX vs SQL Data Source to Read Data Table [closed]

问题: Closed. This question is opinion-based. It is not currently accepting answers....

问题:

I am currently working on a project where I need to read a table from my SQL server and load it into a table on the web page on page load.

I currently can think of two ways to implement this:

  1. On the Page_Load() call, read from the database and dynamically construct the table.
  2. Use an SQL Data Source object to read it in and then display it using a GridView

I can't think of other options, but from experience with both, they both seem to really take a toll on the runtime. On my current PC, it doesn't seem to be an issue due to its high specs. But when I try running it on other PCs at work, it takes a while for the page to load.

Ideally, I want to be able to do this quickly to improve the user experience. And I can't just put the data in manually because my boss wants it to read from the database for easier management and updating.

So, which of the two ways to implement it is faster and/or better design-wise? If there is another option, what is it? I've been personally learning front-end and back-end stuff informally since I started this project.


回答1:

What is best?

Really depends on the solution. But SQL Data Source object is generally a safe and reliable method. Nothing wrong with ajax though. As newer tech comes out you will find that C# is moving away from front end code. It will alter only be razor/blazor pages. Some might be good to pickup those habits. Thus sql datasource.

What I Recommend

I have two go-to solutions that I generally use:

  • For heavy duty SQL projects I use EntityFramework. It's easy to implement and use once you get use to it and you don't have to write SQL.
  • For light-weight SQL projects I use Dapper. It's light weight, you can use code but there are some small plugins and super easy to use.

What causes slow data loading & Solutions

So it might be that your solution works fine, but there are other things that might be slowing it down and it's mainly to do with networking:

  • Size: If the file/data table is very large this will obviously slow things down. The solution is to implement paging or to only select data required.
  • Multiple Calls: Probally the one that slows a search down the most. Many people would place retrieval calls in LOOPS. As a rule of thumb you want to retrieve all your data in 1 call. Use joins, selections and projections to do this.
  • Non-specific connection strings: Using one connection string is generally fine. But if you want to improve performance conciser having read only connection strings. This can be done simple by adding ApplicationIntent=ReadOnly; to your connection string and REALLY improves performance, especially on heavily trafficked DBs. Do this only when you retrieve, not when inserting or updating.
  • Non-Optimized code: Self explanatory, You want to do as little manipulation of the data as possible and want to avoid looping through it multiple times.

I hope some of this helped!

  • 发表于 2020-06-27 22:54
  • 阅读 ( 76 )
  • 分类:sof

条评论

请先 登录 后评论
不写代码的码农
小编

篇文章

作家榜 »

  1. 小编 文章
返回顶部
部分文章转自于网络,若有侵权请联系我们删除