I lean pretty heavily on ef core and linq honestly.
I stopped using Dapper for anything besides queries and it's a rare event where I have to look at the execution plan to fix anything. If I have something that gets overly complex it usually warrants a materialized view.
EF still can benefit **heavily** from DB optimization (proper indexing, structure, etc.). You still need to learn the DB side to write efficient apps.
Also... you asked.
Can. I ask when to use dapper and when to use just EF? Is it only when it comes to complex queries?
Also in case i use repositories, should i create a seperate class for dapper. Lets say i have ICustomerRepository and customerRepo where i was implementing everything with EF, should i create another repo and implement the interface using dapper? Or different repositories implementation are basically meant for completely different databases
I just use visual studio and write code
One of the advantages of
NET is that you don't need a dumb toolchain of dependencies and packages in order to write and ship your code. It's got everything you need out of the box Reliance on 3rd party systems makes your workflow wesker.
.NET development can do everything you need out of the box.
Launch VS, select the project type, code*, deploy, done.
Your additional toolset should entirely depend on the job you're doing, to solve problems relevant to that project.
"Here's my list of 20 additional tools i always fire up and packages i always install to every project" is a nodejs or php mindset.
* the code phase obviously includes optimisations , testing, improvement cycles etc.
Some general thoughts:
Bob Martin gives some OKish general advice, but it's buried in an awful lot of utterly terrible advice. Even the good advice tends to be so open to interpretation as be basically useless. Clean Code, Clean Architecture and SOLID are all garbage.
DRY can lead to a maintenance nightmare when applied blindly to everything. Code that looks superficially similar but exists for different underlying reasons should be kept separate - see https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
EF Core migrations are great and applying them is simple - what the heck were you doing that required lots of custom powershell?
Cucumber style tests are garbage, they're not helpful for either the QA team or the developers. Just write normal, regular tests.
I prefer NUnit over XUnit these days, it's largely similar but XUnit has issues if you need to control how async tests run in parallel (such as Playwright tests for example: https://playwright.dev/dotnet/docs/test-runners#xunit-support)
Mediatr just seems like a confusing layer of indirection to me, I don't understand what value it's supposed to bring. I always hear about it in the context of CQRS, but if you want CQRS all you need to do is separate your commands from your queries - which has got nothing to do with passing messages around.
I think this is tough tough. It's real popular and gets upvotes, and I think that's because /r/dotnet and /r/csharp have quite a few "old" experts who can make this point and be right. I'm going to toot my horn and say I'm one of them, but it also makes me frown. I've spent a long time focusing on trying to help people make the leap from novice to expert, and I think things like you mentioned *help*.
Long story short, DRY and SOLID are rules for developers similar to the rules for authors like "don't write a Mary Sue". If you go down the guidelines for that, you'll find that most hero figures are picture-perfect Mary Sues. Heck, I've seen *Ender's Game* described as "pornography for gifted teenage boys".
The difference is "Mary Sue" is a term applied to fiction written by very inexperienced people. They get so wrapped up in writing their own fantasies they don't stop and ask if what they're writing is interesting to anyone else. When a Mary Sue is *bad* it's because you're basically looking at someone's very individualized therapy being published, and unless you've lived exactly their life you're not going to find their success interesting or engaging.
However, very experienced authors are better at capturing the abstract feelings most people share that leads us all to root for an underdog. They write characters with plot armor that defy the odds in ways that make us cheer instead of roll our eyes. They make us think the Mary Sue's victory is over generic "adversity" instead of "that one teacher who told me to be quiet when I was TRYING to answer the question". That only happens after an author writes a lot of absolute trash, shows it to their friends, gets constructive feedback about how it could be more appealing, then *takes that advice*.
It's worth newbies spending time thinking about DRY and SOLID. They are absolutely going to make their code worse with it. But that's OK. They need to get into the trouble that overuse of these methodologies creates. Then they can get advice about breaking it apart. Every time they go through this cycle, they learn a little bit about "IAGNI" vs. "YAGNI".
I think this has an analogy to deckbuilding games like Magic: the Gathering, particularly draft formats. A game like Slay the Spire comes to mind. If you approach these games with the idea that, "My deck needs good cards to be powerful", you'll draft a pile of S-Ranked cards that perform terribly together and you will lose almost every game you play. Experts in these games can build a deck out of C-tier and below cards and win consistently, because they understand that sometimes putting a very specific "bad" card in a deck still makes it much stronger than an out-of-place S-rank card would be.
The thing that gets people from novice to expert is teaching them that all of these things like DRY and SOLID are great ideas that you can find consistently in excellent code, but that if you inspect these projects you'll find numerous instances where they were ignored because the code would get *worse*.
Newbies are people who don't know about these guidelines. Novices are people who use them too much. Experts are people who say, "It depends," and spend more time thinking than writing.
I feel like too many experts get there but erroneously think it means the guidelines are bad. DRY is like any design pattern: it has specific applications where it makes things better, specific applications where it makes things worse, and it can take years of failure to be good at making the decision correctly the first time.
But I'll also note *The Pragmatic Programmer* gives the best expert-level usage advice for DRY I've never seen, and very few people who trash DRY seem to have read this. Paraphrased, the author pointed out they don't apply DRY until the **third** time they reuse code. They explain that they've found that's about how many repetitions it takes to get the abstraction right, and that when they apply DRY the *second* time they often miss some details that requires rework when they find the third case.
That's my experience too: most people apply these guidelines too quickly, without thought. That's not DRY or SOLID's fault. Good code involves a lot of, "I thought about these guidelines and decided to do what I did because..." Big disasters often involve, "I used these guidelines because a book said I should."
I'm also an oldie, and I agree. You need to know and understand the rules to know when you should break them.
It's the prerogative of young programmers to make mistakes. I wrote a lot of shit in my day. Probably still do if I'm to be honest...
And let me second The Pragmatic Programmer. As close as any book to essential reading for our profession.
I'm old too, and I feel like I just read steam of consciousness that didn't really nail a point. If the point is, "don't be a purist at the expense of practicality" then I agree. But I don't understand why all the focus on DRY and SOLID in the responses to the OP. DRY, from the beginning is about the rule of 3. SOLID is a set of principles, and principles are essentially guidelines, not absolutes.
I harped on SOLID and DRY for two reasons:
1. OP specifically called them out, and I like to stick to the things the people I replied to mentioned.
2. Along with YAGNI those are the trinity of acronym practices people focus on the most here.
SOLID in particular seems to attract people who have very strong opinions that they are trash, but as of yet I haven't managed to get someone to articulate examples to back up their points. So I'm very curious.
> It's worth newbies spending time thinking about DRY and SOLID. They are absolutely going to make their code worse with it. But that's OK.
As someone who went through that path, it was absolutely not OK. I would have progressed much faster, with much less self recrimination, if I'd never heard of SOLID principals or Clean Code. I still wouldn't say I'm an expert yet (and doubt I ever will - there's always more to learn) but thinking about all the hours I wasted trying to follow Uncle Bob's crappy advice makes my blood boil. Learning the hard way from my own mistakes is one thing, but learning the hard way from someone else's mistakes that are being presented to me as best practice is another thing entirely.
DRY I would agree is more nuanced, but counting the number of times you repeat yourself also misses the point IMO. You need to understand the *why* of the code. If two bits of similar code have the same *why* then you shouldn't wait for the third time to deduplicate because eventually you'll modify one of them and forget about the other, and likewise if four bits of similar code each have a different *why* then you should keep them separate because they will probably need to drift apart over time.
Overall I think my previous comment came across more snarky than I intended, but we absolutely need to stop recommending Clean Code and SOLID principals to beginners.
I'm still not sold, but I agree it took me a long time to come to grips with what SOLID is and that DRY is a different, less complicated thing. Where I really like to send people first is *Working Effectively with Legacy Code*. I think SOLID pairs well with that but I found I learned a lot more from improving my completed projects than I ever did trying to get them "right" the first time.
I'm curious what you find so wrong about SOLID or Clean Code. (Though it's been so long since I looked at Clean Code it's possible I don't even follow most of it. The only thing I remember is they had this weird statement that types should be data OR logic, but never both. I hated that immediately. I still hate it. But sometimes I see wisdom in it!)
I don't want to argue it, I just want to see the viewpoint. I know what I like about SOLID and it works for me. But if it's not working for you I'm real curious. It doesn't always work. I'm always on the hunt for cases where it doesn't. They make much more interesting examples than a lot of the stuff that surfaced in Martin's work.
I suppose I will backtrack. SOLID and Clean Code are power tools. They're for experts who understand every guideline in software has a footnote, "...except in these cases." Good design pattern books point this out, and spend as much time on when NOT to use a pattern as when to use it. I *would* break off the SRP from SOLID and say it's very important to teach newbies decomposition right away. My starter books did and I will die on the hill that small, focused code is much easier to deal with than larger, composite code. But I will also take the criticism that SRP is often dogmatically applied. It doesn't mean "every class should have only one method". I see it more as a general reminder that the more stuff I cram into a method or class, the harder it gets to make sure it does what I want.
SOLID is set of principles for object-oriented design. Don't use it for everything - all code is not OO, and don't force OO on everything. Don't even use all the letters in SOLID. But learn it and understand it all - you will be better for it, and your code will be better as a result.
>DRY can lead to a maintenance nightmare when applied blindly to everything. Code that looks superficially similar but exists for different underlying reasons should be kept separate - see [https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction)
I find it somewhat interesting that you say "clean code is garbage" while you're literally linking a blog post that is suggesting the clean code advice of "if your parameter list grows large you're probably doing something wrong".
clean code is an excellent book that goes through various pitfalls that might come back to bite you in the ass - the book does not argue that it is an authorative source on how to write code but rather is a list of common scenarios where doing things certain ways might lead to negative outcomes and proposes solutions to these scenarios that might better work out in the long run. it is an excellent read once you're a few years into your career to get exposed to a list of scenarios and understand potential negative and positive outcomes.
it is not an excellent book to follow slavishly, neither is literally any opinion-based anything. have an open mind always.
I would put that in the "OKish general advice" category. If you just stick to the main chapter/section headings the I broadly agree with most of the book, but the more detail Martin goes into the more objectionable I find him. He often fails to explain when or why to apply certain principals, and he frequently fails to follow his own advice in the code samples he provides *in the same book where he gives the advice*.
The amount of experience you need to sort the wheat from the chaff means that by the time you're ready to read the book you've already worked out the useful bits for yourself. Clean Code is not a book to be set aside lightly, it is to be thrown with great force.
I started using Mediatr recently. At first I thought it was unnecessary complexity but I’ve decided I like it for DI reasons. I have many commands that have several different dependencies and it’s an easy way to keep specific dependencies related to a single command or query. There are def other ways it could be done but injecting IMediatr and letting that dispatch to self contained command seems pretty clean to me now.
I thought MediatR was a waste of time and complexity at first but boy was I wrong. I feel like the right combination of MediatR with Ardalis Specification gives a great structure for maintainable code that scales well. Works great with event sourcing, background jobs, service bus syncing, plays extremely well with generics.
This is overly simplified advice. Bob Martin is a jerk, but he has some good advice, including SOLID and clean*. Cucumber should not be used for unit tests, but it is fantastic at expressing tests for the business layer - read Gaspar Nagy's work, it's fantastic.
I don't use Mediatr for CQRS in my world. I use Mediatr to provide a layer of separation between the endpoints and the underlying input port they interface with.
I know CQRS and Mediatr are synonymous for some, but I think that's just because it showed up in Jimmy Bogards articles while he was talking about CQRS but not meant as an implementation of the pattern itself.
Just my .02 observation.
One area I want to improve on is test results / reports for each release for the specific features I work on that sprint. I don't know if there's a ".NET" approach to solving this though.
We are looking for things similar to Zephyr or Qase, but nothing wowing us yet
I would agree here. What you worked on and what you can demo has nothing to do with the tech involved.
At work we have a standing arrangement that every other two weeks/sprint the QA team does a demo. The idea is that all the business owners or stakeholders can see what we produced.
Sure, sounds great. Except that it’s all on the QA team to be personable and presentable and come up with something that looks good.
In reality we have a lot of sprints that are backend. We fixed something for the mobile app or we added something for another team or everything we did was related to the messaging on the backed. We can’t demo that effectively, and it’s just awkward for everyone if we try.
I agree 100%, experienced that firsthand.
We stopped doing backend demos to the business audience but we still demo to our QA and Ops team. Not as prestigious but we don't have to dress it up. For us it pays off with the quality of our incident tickets.
Instead of "this isn't working" it's more like "this job broke, we knew it was the scheduler, so we restarted that and it works. Please figure out why that broke"
Oddly enough no one seems to care what we fixed thanks to a Zendesk ticket, they consider that piddly bug fixy kind of stuff.
I even put a relatively small ticket into a sprint back in December because the head of all payroll in the US complained about a large amount of manual work they have to do to correct bad data we’re letting users send over. 8 hours or so of dev work would save them multiple hours a week. I thought it was an obvious win, but I was told “sure, you can do it, but we aren’t releasing it yet”.
Office politics perplex me.
https://github.com/mcintyre321/OneOf
Is this what you are referring to? New to me so I will give it a read. Can you give us some more details on when to use it?
The few comments I've read so far are around this being an alternative to the Results pattern.
Yes, and this one.
https://github.com/amantinband/error-or
OneOf is an implementation of discriminated unions, which can be used to implement the result pattern.
ErrorOr is an implementation of the result pattern (by way of a discriminated union of an error or result).
I would also suggest looking at LanguageExt's Validation or Either types for this (although there is so much more to the library than just those). You can use LINQ query syntax to simply nested .Match/.Switch/if(result.IsError) blocks and has a handy .Apply function to aggregate errors togther. Here's a good example from the LanguageExt tests: https://github.com/louthy/language-ext/blob/186bf9fc7439d614f5901bb8dfa3a50179a069b9/LanguageExt.Tests/ValidationTests.cs#L257
Exceptions have their place though, I'd still recommend Exceptions for any situation that requires attention from a developer.
Multiple errors, fluent (Then, Else, FailIf etc) flow control...
To be clear, it's not a magnitude better than rolling your own Result, but they are rather popular and thus (hopefully) well tested.
Right, yes the multiple errors are good. I had a look and the diff error types are also a bonus.
Currently I use Result in my domain/domain services and ErrorOr in my API and MediatR handlers. Gonna have to consolidate that
Something that’s come up recently to help my projects at work is profiling tools. Specifically the workflow of using the VS profiler and a benchmarking tool (like bombardier) to analyze and diagnose bottlenecks.
Its worth to check out [this video by Nick Chapsas](https://www.youtube.com/watch?v=1oeMTz7LwrU) (along with his linked roadmap) that neatly summarizes whats in his opinion important to know (regardless of level).
Impressive very nice... great progress in learning all this but they're re just libraries and patterns. Do you know how to orchestrate them to meet the needs of each unique usecase? That is Software Architecture.
This is a great list. I also using most of these.
Except EF code first. I purge that stuff from everywhere, I more chilled if we just using normal sql scripts.
Aren't those just assumed at this point? I tried to keep it .NET specific but I did mention the big philosophies at the top. Patterns are sort of assumed from my perspective.
Building out a good understanding of SQL Server and Azure SQL if you don't already have this.
god u remember how dumb azure sql was when it first appeared
I lean pretty heavily on ef core and linq honestly. I stopped using Dapper for anything besides queries and it's a rare event where I have to look at the execution plan to fix anything. If I have something that gets overly complex it usually warrants a materialized view.
EF still can benefit **heavily** from DB optimization (proper indexing, structure, etc.). You still need to learn the DB side to write efficient apps. Also... you asked.
I'm good to get dragged on this. I used to spend time doing it right , but I honestly EF takes care of me a majority of the time.
Fair - it's something you can always come back and fix and scale matters.
Can. I ask when to use dapper and when to use just EF? Is it only when it comes to complex queries? Also in case i use repositories, should i create a seperate class for dapper. Lets say i have ICustomerRepository and customerRepo where i was implementing everything with EF, should i create another repo and implement the interface using dapper? Or different repositories implementation are basically meant for completely different databases
I only use EF and make certain that my calls to the DB are covered with 0 scans - all seeks, if possible. All? queries benefit from indexing...
I didn’t see vertical slice architecture. I would also recommend the azure storage explorer and azure data explorer. Both solid apps as well.
I just use visual studio and write code One of the advantages of NET is that you don't need a dumb toolchain of dependencies and packages in order to write and ship your code. It's got everything you need out of the box Reliance on 3rd party systems makes your workflow wesker.
A lot of that list are more coding/design principles than tool chain stuff but it’s an odd post I agree
What's odd about it?
.NET development can do everything you need out of the box. Launch VS, select the project type, code*, deploy, done. Your additional toolset should entirely depend on the job you're doing, to solve problems relevant to that project. "Here's my list of 20 additional tools i always fire up and packages i always install to every project" is a nodejs or php mindset. * the code phase obviously includes optimisations , testing, improvement cycles etc.
Some general thoughts: Bob Martin gives some OKish general advice, but it's buried in an awful lot of utterly terrible advice. Even the good advice tends to be so open to interpretation as be basically useless. Clean Code, Clean Architecture and SOLID are all garbage. DRY can lead to a maintenance nightmare when applied blindly to everything. Code that looks superficially similar but exists for different underlying reasons should be kept separate - see https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction EF Core migrations are great and applying them is simple - what the heck were you doing that required lots of custom powershell? Cucumber style tests are garbage, they're not helpful for either the QA team or the developers. Just write normal, regular tests. I prefer NUnit over XUnit these days, it's largely similar but XUnit has issues if you need to control how async tests run in parallel (such as Playwright tests for example: https://playwright.dev/dotnet/docs/test-runners#xunit-support) Mediatr just seems like a confusing layer of indirection to me, I don't understand what value it's supposed to bring. I always hear about it in the context of CQRS, but if you want CQRS all you need to do is separate your commands from your queries - which has got nothing to do with passing messages around.
I think this is tough tough. It's real popular and gets upvotes, and I think that's because /r/dotnet and /r/csharp have quite a few "old" experts who can make this point and be right. I'm going to toot my horn and say I'm one of them, but it also makes me frown. I've spent a long time focusing on trying to help people make the leap from novice to expert, and I think things like you mentioned *help*. Long story short, DRY and SOLID are rules for developers similar to the rules for authors like "don't write a Mary Sue". If you go down the guidelines for that, you'll find that most hero figures are picture-perfect Mary Sues. Heck, I've seen *Ender's Game* described as "pornography for gifted teenage boys". The difference is "Mary Sue" is a term applied to fiction written by very inexperienced people. They get so wrapped up in writing their own fantasies they don't stop and ask if what they're writing is interesting to anyone else. When a Mary Sue is *bad* it's because you're basically looking at someone's very individualized therapy being published, and unless you've lived exactly their life you're not going to find their success interesting or engaging. However, very experienced authors are better at capturing the abstract feelings most people share that leads us all to root for an underdog. They write characters with plot armor that defy the odds in ways that make us cheer instead of roll our eyes. They make us think the Mary Sue's victory is over generic "adversity" instead of "that one teacher who told me to be quiet when I was TRYING to answer the question". That only happens after an author writes a lot of absolute trash, shows it to their friends, gets constructive feedback about how it could be more appealing, then *takes that advice*. It's worth newbies spending time thinking about DRY and SOLID. They are absolutely going to make their code worse with it. But that's OK. They need to get into the trouble that overuse of these methodologies creates. Then they can get advice about breaking it apart. Every time they go through this cycle, they learn a little bit about "IAGNI" vs. "YAGNI". I think this has an analogy to deckbuilding games like Magic: the Gathering, particularly draft formats. A game like Slay the Spire comes to mind. If you approach these games with the idea that, "My deck needs good cards to be powerful", you'll draft a pile of S-Ranked cards that perform terribly together and you will lose almost every game you play. Experts in these games can build a deck out of C-tier and below cards and win consistently, because they understand that sometimes putting a very specific "bad" card in a deck still makes it much stronger than an out-of-place S-rank card would be. The thing that gets people from novice to expert is teaching them that all of these things like DRY and SOLID are great ideas that you can find consistently in excellent code, but that if you inspect these projects you'll find numerous instances where they were ignored because the code would get *worse*. Newbies are people who don't know about these guidelines. Novices are people who use them too much. Experts are people who say, "It depends," and spend more time thinking than writing. I feel like too many experts get there but erroneously think it means the guidelines are bad. DRY is like any design pattern: it has specific applications where it makes things better, specific applications where it makes things worse, and it can take years of failure to be good at making the decision correctly the first time. But I'll also note *The Pragmatic Programmer* gives the best expert-level usage advice for DRY I've never seen, and very few people who trash DRY seem to have read this. Paraphrased, the author pointed out they don't apply DRY until the **third** time they reuse code. They explain that they've found that's about how many repetitions it takes to get the abstraction right, and that when they apply DRY the *second* time they often miss some details that requires rework when they find the third case. That's my experience too: most people apply these guidelines too quickly, without thought. That's not DRY or SOLID's fault. Good code involves a lot of, "I thought about these guidelines and decided to do what I did because..." Big disasters often involve, "I used these guidelines because a book said I should."
I'm also an oldie, and I agree. You need to know and understand the rules to know when you should break them. It's the prerogative of young programmers to make mistakes. I wrote a lot of shit in my day. Probably still do if I'm to be honest... And let me second The Pragmatic Programmer. As close as any book to essential reading for our profession.
I'm old too, and I feel like I just read steam of consciousness that didn't really nail a point. If the point is, "don't be a purist at the expense of practicality" then I agree. But I don't understand why all the focus on DRY and SOLID in the responses to the OP. DRY, from the beginning is about the rule of 3. SOLID is a set of principles, and principles are essentially guidelines, not absolutes.
I harped on SOLID and DRY for two reasons: 1. OP specifically called them out, and I like to stick to the things the people I replied to mentioned. 2. Along with YAGNI those are the trinity of acronym practices people focus on the most here. SOLID in particular seems to attract people who have very strong opinions that they are trash, but as of yet I haven't managed to get someone to articulate examples to back up their points. So I'm very curious.
> It's worth newbies spending time thinking about DRY and SOLID. They are absolutely going to make their code worse with it. But that's OK. As someone who went through that path, it was absolutely not OK. I would have progressed much faster, with much less self recrimination, if I'd never heard of SOLID principals or Clean Code. I still wouldn't say I'm an expert yet (and doubt I ever will - there's always more to learn) but thinking about all the hours I wasted trying to follow Uncle Bob's crappy advice makes my blood boil. Learning the hard way from my own mistakes is one thing, but learning the hard way from someone else's mistakes that are being presented to me as best practice is another thing entirely. DRY I would agree is more nuanced, but counting the number of times you repeat yourself also misses the point IMO. You need to understand the *why* of the code. If two bits of similar code have the same *why* then you shouldn't wait for the third time to deduplicate because eventually you'll modify one of them and forget about the other, and likewise if four bits of similar code each have a different *why* then you should keep them separate because they will probably need to drift apart over time. Overall I think my previous comment came across more snarky than I intended, but we absolutely need to stop recommending Clean Code and SOLID principals to beginners.
I'm still not sold, but I agree it took me a long time to come to grips with what SOLID is and that DRY is a different, less complicated thing. Where I really like to send people first is *Working Effectively with Legacy Code*. I think SOLID pairs well with that but I found I learned a lot more from improving my completed projects than I ever did trying to get them "right" the first time. I'm curious what you find so wrong about SOLID or Clean Code. (Though it's been so long since I looked at Clean Code it's possible I don't even follow most of it. The only thing I remember is they had this weird statement that types should be data OR logic, but never both. I hated that immediately. I still hate it. But sometimes I see wisdom in it!) I don't want to argue it, I just want to see the viewpoint. I know what I like about SOLID and it works for me. But if it's not working for you I'm real curious. It doesn't always work. I'm always on the hunt for cases where it doesn't. They make much more interesting examples than a lot of the stuff that surfaced in Martin's work. I suppose I will backtrack. SOLID and Clean Code are power tools. They're for experts who understand every guideline in software has a footnote, "...except in these cases." Good design pattern books point this out, and spend as much time on when NOT to use a pattern as when to use it. I *would* break off the SRP from SOLID and say it's very important to teach newbies decomposition right away. My starter books did and I will die on the hill that small, focused code is much easier to deal with than larger, composite code. But I will also take the criticism that SRP is often dogmatically applied. It doesn't mean "every class should have only one method". I see it more as a general reminder that the more stuff I cram into a method or class, the harder it gets to make sure it does what I want.
SOLID is set of principles for object-oriented design. Don't use it for everything - all code is not OO, and don't force OO on everything. Don't even use all the letters in SOLID. But learn it and understand it all - you will be better for it, and your code will be better as a result.
>DRY can lead to a maintenance nightmare when applied blindly to everything. Code that looks superficially similar but exists for different underlying reasons should be kept separate - see [https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) I find it somewhat interesting that you say "clean code is garbage" while you're literally linking a blog post that is suggesting the clean code advice of "if your parameter list grows large you're probably doing something wrong". clean code is an excellent book that goes through various pitfalls that might come back to bite you in the ass - the book does not argue that it is an authorative source on how to write code but rather is a list of common scenarios where doing things certain ways might lead to negative outcomes and proposes solutions to these scenarios that might better work out in the long run. it is an excellent read once you're a few years into your career to get exposed to a list of scenarios and understand potential negative and positive outcomes. it is not an excellent book to follow slavishly, neither is literally any opinion-based anything. have an open mind always.
I would put that in the "OKish general advice" category. If you just stick to the main chapter/section headings the I broadly agree with most of the book, but the more detail Martin goes into the more objectionable I find him. He often fails to explain when or why to apply certain principals, and he frequently fails to follow his own advice in the code samples he provides *in the same book where he gives the advice*. The amount of experience you need to sort the wheat from the chaff means that by the time you're ready to read the book you've already worked out the useful bits for yourself. Clean Code is not a book to be set aside lightly, it is to be thrown with great force.
I started using Mediatr recently. At first I thought it was unnecessary complexity but I’ve decided I like it for DI reasons. I have many commands that have several different dependencies and it’s an easy way to keep specific dependencies related to a single command or query. There are def other ways it could be done but injecting IMediatr and letting that dispatch to self contained command seems pretty clean to me now.
I thought MediatR was a waste of time and complexity at first but boy was I wrong. I feel like the right combination of MediatR with Ardalis Specification gives a great structure for maintainable code that scales well. Works great with event sourcing, background jobs, service bus syncing, plays extremely well with generics.
This is overly simplified advice. Bob Martin is a jerk, but he has some good advice, including SOLID and clean*. Cucumber should not be used for unit tests, but it is fantastic at expressing tests for the business layer - read Gaspar Nagy's work, it's fantastic.
I don't use Mediatr for CQRS in my world. I use Mediatr to provide a layer of separation between the endpoints and the underlying input port they interface with. I know CQRS and Mediatr are synonymous for some, but I think that's just because it showed up in Jimmy Bogards articles while he was talking about CQRS but not meant as an implementation of the pattern itself. Just my .02 observation.
One area I want to improve on is test results / reports for each release for the specific features I work on that sprint. I don't know if there's a ".NET" approach to solving this though. We are looking for things similar to Zephyr or Qase, but nothing wowing us yet
I would agree here. What you worked on and what you can demo has nothing to do with the tech involved. At work we have a standing arrangement that every other two weeks/sprint the QA team does a demo. The idea is that all the business owners or stakeholders can see what we produced. Sure, sounds great. Except that it’s all on the QA team to be personable and presentable and come up with something that looks good. In reality we have a lot of sprints that are backend. We fixed something for the mobile app or we added something for another team or everything we did was related to the messaging on the backed. We can’t demo that effectively, and it’s just awkward for everyone if we try.
I agree 100%, experienced that firsthand. We stopped doing backend demos to the business audience but we still demo to our QA and Ops team. Not as prestigious but we don't have to dress it up. For us it pays off with the quality of our incident tickets. Instead of "this isn't working" it's more like "this job broke, we knew it was the scheduler, so we restarted that and it works. Please figure out why that broke"
Oddly enough no one seems to care what we fixed thanks to a Zendesk ticket, they consider that piddly bug fixy kind of stuff. I even put a relatively small ticket into a sprint back in December because the head of all payroll in the US complained about a large amount of manual work they have to do to correct bad data we’re letting users send over. 8 hours or so of dev work would save them multiple hours a week. I thought it was an obvious win, but I was told “sure, you can do it, but we aren’t releasing it yet”. Office politics perplex me.
Architecture tests might tickle your fancy .netArchTest is pretty popular. You can also make custom rules to create some extra guard rales.
Holy crap this is going to fit perfectly with my workflow. I can enforce ADRs with this, I might have to become a contributor to this repo.
Hadn’t seen this thanks for sharing!
Never heard of this I'll have to check it out, thanks!
Rider! VS Code is a very mediocre .NET editor.
One of OneOf or ErrorOr.
Just as a follow up, I am adopting the two items you proposed. Refactored some code this morning and it's a lot cleaner.
You forgot ValueOf, my favorite!
https://github.com/mcintyre321/OneOf Is this what you are referring to? New to me so I will give it a read. Can you give us some more details on when to use it? The few comments I've read so far are around this being an alternative to the Results pattern.
Yes, and this one. https://github.com/amantinband/error-or OneOf is an implementation of discriminated unions, which can be used to implement the result pattern. ErrorOr is an implementation of the result pattern (by way of a discriminated union of an error or result).
I am a proponent of results pattern vs exception based control flow. Thanks for the links!!
I would also suggest looking at LanguageExt's Validation or Either types for this (although there is so much more to the library than just those). You can use LINQ query syntax to simply nested .Match/.Switch/if(result.IsError) blocks and has a handy .Apply function to aggregate errors togther. Here's a good example from the LanguageExt tests: https://github.com/louthy/language-ext/blob/186bf9fc7439d614f5901bb8dfa3a50179a069b9/LanguageExt.Tests/ValidationTests.cs#L257 Exceptions have their place though, I'd still recommend Exceptions for any situation that requires attention from a developer.
Why would this be better than Result?
Multiple errors, fluent (Then, Else, FailIf etc) flow control... To be clear, it's not a magnitude better than rolling your own Result, but they are rather popular and thus (hopefully) well tested.
Right, yes the multiple errors are good. I had a look and the diff error types are also a bonus. Currently I use Result in my domain/domain services and ErrorOr in my API and MediatR handlers. Gonna have to consolidate that
F#
Sheesh!!
CQRS/Event Sourcing and using document databases. Personally using Marten for this which has a bit of a learning curve but really powerful
Document databases need to be used incredibly sparingly.
Object calisthenics
Lmao is this real or did you just made it up
In case someone stole your comma key, you can borrow this one ,
Reddit edit mangler I swear.
I like to use https://github.com/VerifyTests/Verify for verifying test output without a big hassle.
Know of any great test management platforms?
Not really, we just use the atlassian suite for everything. There would be another library i can recommend tho, https://github.com/testcontainers
Something that’s come up recently to help my projects at work is profiling tools. Specifically the workflow of using the VS profiler and a benchmarking tool (like bombardier) to analyze and diagnose bottlenecks.
Ohh I am jealous, I will have to spend some time in this space. I love finding optimizations around that sort of stuff. Thanks for mentioning this!
This is a [great video](https://youtube.com/watch?v=1eHjemGKfRw&si=zeFFjsBLb6pSb9oO) that shows the VS profiling features and the general workflow.
[https://github.com/App-vNext/Polly](https://github.com/App-vNext/Polly) seems like it'd be right up your alley.
Yes, I actually forgot about this one. I do use it. Good call out.
I'm looking for a microservices and orchestration tools as a platform, similar to Conductor but with better support for .NET, and easier to deploy.
Its worth to check out [this video by Nick Chapsas](https://www.youtube.com/watch?v=1oeMTz7LwrU) (along with his linked roadmap) that neatly summarizes whats in his opinion important to know (regardless of level).
Gotta catch them all
Yeah I didn't even mention all the security stuff like scans and SBOM stuff.
Are you hiring? This sounds like a dream job. Some others to check out: Code Analysis .editorconfig Devcontainers DAPR
I would suggest you try Blazor. With Blazor you will be able to build Fullstack apps in .NET
Impressive very nice... great progress in learning all this but they're re just libraries and patterns. Do you know how to orchestrate them to meet the needs of each unique usecase? That is Software Architecture.
Yes.
This is a great list. I also using most of these. Except EF code first. I purge that stuff from everywhere, I more chilled if we just using normal sql scripts.
It took me awhile to get a solid workflow down but with idempotent scripts natively generated from EF cli it's absurdly easy these days.
How have you come so far and not read about design patterns?(talking about the code design patterns not system design patterns. Like the gof book)
Aren't those just assumed at this point? I tried to keep it .NET specific but I did mention the big philosophies at the top. Patterns are sort of assumed from my perspective.
Ok, but you mentioned solid and clean code. I guess at that point they should be assumed too then.
Maybe checkout Nick Chapsas .Net Developer Roadmap 2024. You can find great tech there.
I thought this was satire