[flagged]
[deleted]
Understanding the .NET ecosystem: The evolution of .NET into .NET 7
111–120 of 357 posts
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#112Earlier quoted context omitted.
It really is like finding enlightenment after having to figure out which third party package is best for every little thing in Node. Visual Studio is a pretty powerful IDE as well.
Jetbrains Rider is great for .NET too, although I didn't try backend developement with it.
It’s awesome. What I enjoy most is, that all the different tools feel the same, and you can use the same kind of IDE also for web developmen, JavaScript and SQL. Rider also has webstorm and datagrip bundled as a plug in, so you can also do everything in one IDE. I prefer though to use the standalone tools for that, they have just less features than rider/IntelliJ, but i would consider that a plus. Less menu items, less tool windows.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#113Earlier quoted context omitted.
What would you like build-in db stuff to be like?
Well I mean DataTable and friends can handle master-detail for example, but you gotta do a lot of plumbing to set it all up, especially with autoincs involved. Was kinda expecting it to be less work. Ideally I'd like to supply some selects, fill up some DataTables with master-detail data, manipulate it and commit changes. But yeah, maybe I gotta check out the latest EF stuff and see if I can't convince the others...
Just do yourself a favor and don’t use datatables directly. If you want to be as close to the database as possible, check out Dapper. It EF core should cover nearly all Dapper functionality and much more.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#114Earlier quoted context omitted.
>We're moving to .Net, and I was surprised by how poor the built-in DB stuff is Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Although for performance you would probably reach for something like Dapper but that is not an ORM.
Well that was my point, either you're writing a lot of code yourself ("assembly"), or you use EF ("Python"). We're not used to something like EF, perhaps it would work for us. But debugging generated queries due to performance issues is something we'd like to avoid. For now the decision was made to not use EF.
EF Core generates pretty good queries for common cases. I'm not entirely sure about really complex analytical queries, but you might want drop down to SQL for those anyway.
There is one gigantic footgun in EF Core, that is the decision between single query and split query. If you choose single query in the wrong situation you can end up with truly pathological queries. I might blame EF Core here a bit for a dangerous default, but to be honest the other choice would be dangerous in a different way, so there is no obvious good default choice here. This is a part that you need to understand to use this ORM, and fortunately it generates warnings now and kind of forces you to choose the strategy.
The one other aspect that helps to generate good queries with EF Core is to use "Select()" for any case where you want to request fewer columns than available in your tables. I find it quite natural to write queries this way in any case.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#115Earlier quoted context omitted.
>It's like either assembly or Python, but nothing in the middle. Dapper seems to be in the middle and it is pretty popular
Yeah, but from what I saw it doesn't help much with master-detail setups? Like, inserting or updating an order with order lines etc. We rely heavily on those.
It can. Basically you separate the query response by the parent and child in the row using `SplitOn` and it can materialize it.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#116Earlier quoted context omitted.
Well I mean DataTable and friends can handle master-detail for example, but you gotta do a lot of plumbing to set it all up, especially with autoincs involved. Was kinda expecting it to be less work. Ideally I'd like to supply some selects, fill up some DataTables with master-detail data, manipulate it and commit changes. But yeah, maybe I gotta check out the latest EF stuff and see if I can't convince the others...
DataTables are a construct from .NET Framework 1.1. You owe yourself (and would be doing your employer a massive favour) to check out EF Core.
Well that'd explain why they feel clunky :D
Will def look at it more carefully.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#117Earlier quoted context omitted.
>We're moving to .Net, and I was surprised by how poor the built-in DB stuff is Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Although for performance you would probably reach for something like Dapper but that is not an ORM.
Well that was my point, either you're writing a lot of code yourself ("assembly"), or you use EF ("Python"). We're not used to something like EF, perhaps it would work for us. But debugging generated queries due to performance issues is something we'd like to avoid. For now the decision was made to not use EF.
You can use EF Core also with plain SQL queries, if you don’t like/trust the query builder. You can also disable change tracking completely, if you prefer to only INSERT/UPDATE directly with SQL statements. You get a lot of awesome features, but nobody forces you to use them.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#118It’s a tired thing to say, but the “.NET” naming is so confusing on what’s what. Which is sad because there’s so much to like about .NET
Isn't Java world a lot more confusing? You have Java language, Java compiler, Java class library, Java Virtual Machine, Java bytecode, Java runtime environment, Java development kit (OpenJDK - is it open? how many forks are there?), Java SE, ME, EE, JavaBeans. What can you use where, what is the license, who made what, what role does Oracle play? So many questions in a universe where google doesn't exist to clear up…
I Googled “.NET assembly loading”. The second hit is “Understanding How Assemblies Load in C# .NET”, [0], from July 2020, 4 months before the RTM release of the unified .NET 5. While this post mentions .NET Core by name once, this post is completely irrelevant to .NET Core/5+ (which threw out the Global Assembly Cache, assembly redirections, and generally simplified everything). How do you find articles that are actually relevant to the modern .NET and not the Framework?
The Java stuff is easy. From the perspective of a Java developer, most of the things you listed (except for ME, EE and JavaBeans) are just “Java”. And they always have been.
[0] https://michaelscodingspot.com/assemblies-load-in-dotnet/
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#119I'd be curious to know what is the actual adoption of .net core. I.e. of all the actively developed applications (not just new projects), what is the .net core / .net framework split. I found that the upgrade process is not seamless. Asp.net core has little to do with asp.net MVC. Winform introduced all sorts of contraints. The BCL is full of small changes or features missing. People are less vocal than for the pytho…
Another thing to keep in mind is Microsoft shops don’t tend to use anything else. So while I’m sure many have not transitioned, it’s basically a forgone conclusion. The competitors to most .net apps are excel and saas.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#120Earlier quoted context omitted.
Usually non-technical persons do not give a faint fart about 'major' 'version numbers'. Is it a thing or goes somewhere? Yet about 'platforms' and 'sofware conventions'. Is it working or not? Usually that's what they care about. So it was ok in the old system but now there is an improved super shiny trendy best superpower new one and the previous ok is not ok anymore? [puzzled faces]
> Usually non-technical persons do not give a faint fart about ‘major’ ‘version numbers’. This type of user is actually usually, IME, easier to explain it to: “It’s a different platform and our software will not work without changes”. The less they “give a faint fart” about details, the easy it is to tell them the effects and have them accept and move on. At most, you might occasionally need to invoke a car analogy:…
The different platform argument was easy to make when it was called ".NET Core". Almost impossible to make when it's also called ".NET", quite deliberately.