Best Practices in .NET I Don't Like Anymore

本站添加: 2026-05-14

[00:00:00]Hello everybody, I'm Nick and in this video I want to talk about some practices that I really loved using when developing software innet which I don't really use anymore and I have alternatives for. Now this is an interesting video I want to make this for a while but the problem is at dome train we have courses on subjects that I'm going to say I don't personally use.

[00:00:18]This doesn't mean that the subjects are not things you should know about but you understand how there could be a bit of a conflict of interest. But I have to try to myself because ultimately you're subscribing to hear my opinion on things. So I might as well stay true to myself and talk about them. And if you check my videos over the years, all of these things at some point I have heavily advocated for. But I've been doing this for 7 years now. And I think it's understandable that as you gain experience and as your workflow changes, you prefer different things as you go and you reject other ideas because they just don't work for you. By no means this is not a recommendation against all of those practices, but I will explain my reasoning as to why I follow each one of those practices. And the first one is clean architecture. Now, I used to love clean architecture. When I joined, I remember my second company, every project there was built in clean architecture. And it was very it was like 2017, so it was still fairly early days on the whole clean architecture movement. And I found it amazing because you can sort of find everything and follow a flow very very quickly.

[00:01:20]However, as I gained experience over the years and I built more and more software, I believe that vertical slice architecture where every feature is separated in its own folder instead of having this idea of the core, the infrastructure, the web and so on. I have found that different approach where every folder is a feature and then in that folder you have any service that you might need any repository any endpoints for said feature to be way way easier to work with and it's for me way more obvious because I can immediately see what's in each folder and if it says it's off then it's off. If it's about the users, it's users. If it's about the basket or any of the other subjects, like it's extremely extremely easy for me to see exactly what I need. You end up with less files. You end up with less project hopping. And you don't need to expand four different projects to know exactly what's happening. if you just want to change one feature. Also, systems architected in that way, especially monoliths are way easier to carve out microservices out of because in theory, all you need to do is take that single folder and then move it into a separate micros service if needed. So, it's extremely extremely easy to work with in my opinion. And as an added benefit today with AI agents, you know, cloud codex and so on, those tools are doing their scan to try to find in different projects where things are, but it's actually quite hard for them to reliably find everything every single time. It takes more thinking power. It makes sense. You have to look into more locations and do all of those project reads and so on. However, I have found that consistently every project I've used an AI agent with that is in vertical slices is significantly faster to develop and it makes less mistakes because it knows where everything is in that folder. Yes, you're going to have things in configuration and other areas.

[00:03:17]But with clean architecture, things are a bit less obvious for an LLM and in my opinion, it's less obvious for a human as well. I think that's why LLMs work better with vertical slices again in my opinion. So I used to heavily advocate for clean architecture and everything around it and we're going to talk about more things in there too. Nowadays I'm leaning towards vertical slices sort of purely and the angle of the LLMs actually working better with vertical slices came up from an attendee for my VIP coding in production workshop which is not about vibe coding it's about proper agentic coding in production.

[00:03:53]Many people have misunderstood this and everyone who was using the vertical slice approach found out that they were getting consistently better results. Now that workshop is still running. It was so successful I'm running it again in July on more North America friendly hours because some people had to join at 3:00 a.m. So if you want to join me, hundreds of people have signed up already both for the online one and for the versions of the workshop on online workshop. So I'm going to put a link in the description if you want to join me and learn why I haven't written in production a single line of code in the past eight months by hand then you should check it out and I've been very successful doing it too. Now before I tell you about some other aspects in clean architecture I don't like so much and we're going to look at them in isolation I want to talk about testing a bit. Now unit testing has been a cornerstone of any software development since forever. Everyone talks about the testing pyramid of how you should have tons of unit tests at the bottom, then some integration tests, and then some end to- end tests. I have found over the years that this doesn't really work for me. Now, don't get me wrong, with LLMs, it's extremely easy to write unit tests, tons of them, very, very quickly.

[00:04:58]However, I don't think you're going to get the same value you're expecting by having tons of unit tests. And instead, I subscribe to a different idea. I've been talking about this for 4 years already. If you've taken my integration course on dom train which is fairly old now but still fully relevant then you know that I don't really like the idea of the testing pyramid and tons of unit tests. Instead I choose to write unit tests from the edge cases that is quite hard for a normal flow to go in and then you have tons of integration tests. You use test containers and you use the web application factory to spin up a server a real server basically to run integration tests against that. And I find that this top tobottom approach to writing and running tests allows you to write tons of integration tests very very quickly. They run very quickly if you do the setup correctly. And I've talked about how to do that as well. And then you end up with this testing diamond where you have a few end to-end tests, tons of integration tests covering basically almost everything and then some unit tests for your edge cases. It's easier to write, easier to manage, way more descriptive, and it tests the system the way your users will interact with it, not necessarily the way the code flow will go down to that nitty-gritty method. I personally find it way better and it's my recommendation for how you should do testing in.NET and probably in other technologies as well, but Net is extremely powerful because of that web application factory and the ability to spin up an inmemory process of your API or service.

[00:06:27]Extremely easy. Hands down massive productivity boost and confidence boost.

[00:06:33]Another thing I don't really use and this is not really controversial. I know tons of you don't use it anymore but for me automapper I used to love automatic mappers. It's not about automapper the library but it's about any mapping library. Yes, even source generated ones. I'm not a big fan. I believe that especially nowadays with LLMs and you see this recurring theme a lot, but it's very relevant. I don't know anybody who is not using an NLM to develop. These mappers can lead to issues. They're conventionbased.

[00:07:07]The idea of having a mapper is extremely valuable. the idea that you have your contract, your DTO, you don't want to change it and break the domain logic and then domain logic shouldn't be exposed to the browser or the API endpoint and then the DTO you have for the database that is a separate thing and they all need to be versioned and controlled differently. The idea of having a mapper makes a lot of sense but for me the way I write mappers is I just create an extension method on the object and I if I want to change the domain object to a response I say to response with that extension method. If I want to turn a DTO to a domain object, I just say your DTO dot to domain and I change it back to that and I just write the mapper and it's not hard at all. The LLM will rarely make errors on that sort of thing. In many cases, it will find issues as well with the way you're doing the mapping and how you expose something. For example, you're using an object for here while you should represent it as an integer or as a GUID or something else. So, a significantly better approach to not use one. I understand that source generated mappers remove the performance hit that you could have with something like automapper. However, I don't think it's about performance. I think it's just about safety of the code and actually controlling what's going on behind the scenes. I don't think we have an excuse now to use any mappers anymore. So, I've sort of moved away from that. And in the same theme, I really do not like mediator libraries. Again, another thing I used to love, I used to like literally advocate for mediator as like this godsend thing. The more I use it, the more I write software, the more I realize what why like why you have a minimal API to controller, then you have the handler, then you have a service in the handler, then you have a repository, and you have this abstraction fetish for absolutely no reason while you could just simplify your stack significantly.

[00:08:57]And you don't have to worry about where the request will go. It's significantly easier to debug as well because when you step into a method, the handler will use magic to send it into the handler and the debugger basically says, "I don't know what to do about it." And yes, there's packages that can make this easier. But like you're trying to fight a problem that shouldn't be there. Why are we using it? Just call the service.

[00:09:20]It is fine. your project will not spontaneously combust because there's not 13 layers of redirection to return a JSON string. Like come on. And yes, this stands true even for the soft generated version of mediator. You really do not need it. At least that's what I think.

[00:09:38]There is no point to it. There is literally nothing wrong with injecting a service in a controller or in a minimal API and calling the service. And the service of course can then call the repository or crazy idea you can call the database from especially if you have ENT framework never use repositories with ENT framework there is literally no point just use the DB context directly you'll be fine remove some of those layers you're over complicating your software for no reason and again I know I've said it before I'm going to say it again because that's where we're heading and we're not coming back from this LLMs find it easier to have less layers for no reason. Basically, they can still work for it, but they're going to be more expensive and slower. Why? No reason. I don't think you should use it.

[00:10:28]I don't use it. The last one might surprise you, but actually it's about EF Core. And it's not that you shouldn't use it. It's that it's fine. Now like many people have this idea that this there's this massive disparity between Dapper and N framework and you should never use EF core because Dapper is so much more performant and everything. I still personally use Dapper for everything. I like this control. I can see the SQL. I can see everything like it's just a better workflow for me. But in the past I have been pretty critical of EF core and I've said basically just don't use it. It's not worth it. It's not performant. Actually pretty good.

[00:11:06]pretty performant, tons of good features. I have used it in the past as like its own thing. I have also used it for my rights. So writes and migrations were done with EF Core and reads were done with Dapper. In this hybrid approach, I think both of them are fine.

[00:11:22]But even if you want to use EF core for both, absolutely fine. I think you shouldn't have to worry about the performance impact. Realistically, it wouldn't be your bigger concern anyway.

[00:11:34]It's very likely the database call that you're going to make to the DB like the actual network hub will take way more than any performance set that EF core will introduce. So absolutely fine library. I still use Dapper and Fluent Migrator or DB up depending on how I'm feeling this week. But if you want to use it, of course, go for it and use it.

[00:11:54]There should be no shame in it. I don't understand the hate anymore. It's like really good. But now I know from you.

[00:11:59]What practice were you following and now you just don't follow anymore because it doesn't make sense for your workflow or you've used it long enough and you just don't think it's worth it? Leave a comment down below and let me know.

[00:12:10]Well, that's all I had for you for this video. Thank you very much for watching and as always keep coding.