As the Gypsy has already listed very well the points of his doubt and responded to the height, I will just suggest some links and make some suggestions for technologies to be used.
How are you using the ASP.NET MVC check if all your Actionare marked with return async Task<>.
So where do you find.:
public class MyController : Controller
{
public ActionResult MyAction(int id)
{
var model = db.Colecao.Find(id);
return View(model);
}
}
change to.:
public class MyController : Controller
{
public async Task<ActionResult> MyAction(int id)
{
var model = await db.Colecao.FindAsync(id);
return View(model);
}
}
The same goes for Webapi, so find yourself.:
public class MyController : ApiController
{
public Entidade MyAction(int id)
{
var model = db.Colecao.Find(id);
return model;
}
}
change to.:
public class MyController : ApiController
{
public async Task<Entidade> MyAction(int id)
{
var model = await db.Colecao.FindAsync(id);
return model;
}
}
With this, you make your Asynchronous Actions, with this simple change your system can come to support thousands of requests per minute, as you can see in the following Artigo/Benchmarking - Node.js vs. IIS + WebAPI async – Performance Test
Now as to Banco de Dados, you can and should make use of and abuse of Entity Framework to speed up its development, just remember to use asynchronous methods whenever they are available.: for example FindAsync, ToListAsync, ToDictionaryAsync, FirstOrDefaultAsync, AnyAsync, MeuMetodoAsync.
But remember, the Entity Framework is just a tool, nothing prevents you from using another in conjunction with it, as for example the Dapper, I advise you to use the Dapper whenever you have a more critical query for the system, either because it is very requested or if you need to write your own SQL, in any case, be sure to use the methods Async, like the QueryAsync
. Here is a link to justify this advice.: Dapper vs Entity Framework vs ADO.NET Performance Benchmarking
As for your front-end, as I do not know the knowledge that your team has of Javascript, I would advise you to put aside the jQuery and use the VueJS, even if they decide to make a Multiple Page Application.
Model
public class Entidade
{
public Int32 EntidadeID { get; set; }
public String Descricao { get; set; }
}
Controller
public class MyController : Controller
{
public async Task<ActionResult> MyAction(int id)
{
var model = await db.Colecao.FindAsync(id);
return View(model);
}
}
Controller
@model Entidade
<div id="conteudo">
<input type="hidden" id="EntidadeID" name="EntidadeID" v-model="EntidadeID">
<label>
Descrição:
<input type="text" id="Descricao" name="Descricao" v-model="Descricao">
</label>
</div>
@section scripts {
<script type="text/javascript">
var model = @(Html.Raw(Newtonsoft.Json.JsonConvert.SerializeObject(Model)));
new Vue({
el: '#conteudo',
data: model
});
</script>
}
At first glance it seems a bad exchange (O Razor for Vue), but remember, you will be transferring the responsibility of rendering the page to the Cliente, and will be much simpler to update the page after requests AJAX (due to bind bi-direcional created by VueJS).
To learn more, visit the links.: VueJS, Vue JS Brasil and Vue.js is easier to learn than jQuery.
Remembering that the adoption of VueJS can be incremental, you don’t need to rewrite your entire application in order to start using the same.
Of course, you may come to make an application SPA, using the Async WebAPI and the Framework JavaScript of your preference, such as Angular, React or the very VueJS, follows a tutorial link VueJS - Single Page Application
I appreciate the tips, and I will certainly look into those cases. The system was developed in 2012, and several developers programmed into the project, each using their development practices, and in some cases, development practices, ta a true Frankenstein. A few weeks ago I even thought about taking a look at this issue of using async in actions, because I needed to use it in a specific action. If I change all actions to async I won’t run the risk of giving any trouble then?
– Yoshitani
In this case, I advise you to do this progressively, write the new features this way, and when you need to change an old one, modify it to fit this new model. As for exchanging Actionresult for async Task<Actionresult>, it should not impact your solution, yet I would make this change slowly.
– Tobias Mesquita