I'd replace Automapper with that instead, it seems to me it causes more problems than it fixes and few understand it properly when it fails. Turning plain and simple mapping into a difficult to debug mess.
@@EbrahimAlkadim and with .NET 5 you actually create a dependency service using the json file created by swagger.... then just add that reference to your project... It can all the API calls for you from the generated code. So in client you already have methods to call the API.
I'm really surprised Noda Time hasn't had a mention. A really good package for allowing dates/times to be tested. It also makes you think about what sort of a date/time you have, UTC, a local date/time or one in another Time zone.
I wonder why MS won't optimize Json.NET internals directly (without breaking public API) to take advantage of Span Family API and reduce allocations. There might be 2 reason which I can think. 1. MS don't want to optimize 3rd party libraries (although the author Newtonsoft works at MS) 2. Or Newtonsoft didn't give the permission to do so!? 😅😅
I think that they have said that already. Can't find the blog. Basically that's what they wanted to do originally but as they tried to do so it was so hard to optimize without making any breaking changes that they dropped the idea. It also has to do with how many projects use it. If they were to break something in the process or cause a memory leak or whatever, they would bascically harm every single .net project.
@@nickchapsas Breaking change that is OK for .NET Core. I mean just get a clone of Json.NET into dotnet runtime (if wanted rename it to System.Text.Json) and optimize its internal for performance! So this way, it will have all features + Perf improvements.
@@titol6 I don't think so when I look at such a mature library like Json.NET. And also the author of library works at Microsoft, so that shouldn't be the problem from my point of view!
I dislike using full ef, however it can be nice to quickly reverse engineer the sql db model into c# using the dotnet ef cli commands, especially when combined with the validation abstraction decorations. It allows you to quickly get the exact models and validation. I would not use those models directly however you can extend those and add whatever alterations you want.
Yeah, I've done it the opposite way as well... where I would use EF with track changes turn off and used dapper with stored procs for my writes. I am not a big fan of putting business logic in stored procs, but in some cases it just makes sense from a performance standpoint.
I've used almost one of each kind of nugets you talked about, thats awesome.. I would like to see a video about MSBuild.. But compiling a project programaticly..
Can you do a video about whether at this time RestSharp is still relevant compared to the actual encarnation of the native .Net HttpClient? Tks in advance.
Very tangentially, I noticed that you are using a Rode NT1-A mic - in addition to software development, I'm also a music producer and think very highly of that model of mic.
I think in 5 years if seen NodaTime once and that one service was doing some time specific things. It’s pretty cool but I wouldn’t put it under a “must know”
2 года назад
@@nickchapsas I would recommend NodaTime in every project instead of BCL DateTime because it has a proper abstraction for date, time, time zones, etc. Even if you don't need advanced date time arithmetic you would use proper abstractions.
JetBrains Annotations is the obvious one missing, first package I add to just about every project I ever make. Log4NET at least worthy of mention next to Serilog too. On a separate note, can we please all agree that anything that depends on coding by convention should die in a fire? It's not discoverable, the only way to know it is to know it already, which means it's just more cruft and guff to learn before you can do anything productive. The worst fad in the last two decades.
Masstransit is very hard to get working and very opinionated, it’s not easy to get going. Brighter I think is a better starter package. I would use nservicebus if my company could afford it.
@@daa82 you should stick to the latest stuff not the older tech, need to keep your skills up to date and go with industry. Microsoft or autofac is what you see in projects and online. "Good" or "better" unfortunately doesnt apply in software.
Hello ! I have a question. I want to execute Javascript (node.js) code on a Web API REST Call (C#). Can I use IJSRuntime ? or it isn't a good practice ? and if so, Is there an alternative to run Javascript code on the back-end side. My app have 2 Parts (backend and a front end app) not a Blazor app.
There is node.js for running JS on the server-side. So you already have .Net app, then you need to run node.js app and all what you need is just think about channel which you will use to trigger node.js functions from your .Net app (it might be HTTP, message queue, whatever)
This certainly looks interesting, I wasn't aware of it. That being said it wouldn't make the list even if I did, at least not the 2021 list. A project needs to be mature, stable and widely used before it can make my "top 20 nuget packages list"
Interesting list. Most are a safe bet for projects, too, or a good start to look for something that fit the particular use-case better. I don't think Serilog should be on the list, but that's more a personal preference than anything else. That said, thumbs down for suggesting using two ORMs at once instead of just learning SQL. That's just lazy.
I disagree. It’s not lazy, it’s efficient. Why would I spend time learning something in depth that I really don’t need to? It’s actually been 4 years since I used an RDBMS professionally at all but when I have to Dapper and EF give pretty much the exact same results without me having to be good at SQL. It’s an absolute win
@@rahulj2167 agree. Knowing sql is a must when it comes down to Sql optimisation. Developer needs to know execution plan more or less. Some times orm spits urgly query lowering performance, that’s when raw Sql comes in handy.
@@restveggie6155 Yes. My point was there is no harm in including Dapper, EF under tools for a .Net developer to get familiar with. Each has its use cases.
