Thanks a lot for your videos. They are always well explain and with a nice tempo. I would like to know how you go about using cross-cutting concerns in your static behavioural classes without DI. Personally, I wouldn't find practical passing a logging or a context , to put an example, dependency as a parameter to the methods.
Thank you L. D. for your kind words and comments. Great question indeed. I only log and handle exceptions in one place in my entire system. This is at the "entry point" of my applications. So in ASP.NET Core applications, I'd do this in an exception handling middleware. More specifically, my domain layer will never catch exceptions ( will happily throw lots of exceptions, however), so all exceptions will fly out (walk up the call stack) and will be caught only at the entry point. I've never had the need, nor seen the need to log or catch exceptions in every class, method etc. Additionally, catching exceptions at the point of entry also provides access to the inputs into the system, thus that information is available to log and additionally can also be used to reproduce the issue if needed. Hope this makes sense?
@@Matlus I agree with that approach to error handling. But I was thinking more like logging at information and warning levels (which is kind of a must on microservices applications), tracing, accessing to caches, and all the other factories and providers that are implemented in the framework. I'm cannot see how to implement these using static methods. At the other hand, there is always the possibility to create DI singletons.
@@lutfidwedari If I do have a need to log at more detailed levels (Its been over a decade since I've had that need) I'd still log at the entry point rather than all over the place in the system. If you do go the route of using an instance/singleton, I'd say you're damaging the design of your system for the sake of a "may be" :) situation. With today's trace capabilities and (tracing between system calls) I'd have to hear a really good case to justify logging in multiple places and the damage (this causes). I think (from similar discussions with my colleagues and other architects) that there is something else my my designs and implementations (for eg. "lock the front door, lock the back door and you're safe in the house" and "Programming to Exceptions") that negates the need for logging. Or maybe it's the level/extent/style of testing my systems where in production I'm never left wondering what's going on. I only log technical exceptions (even though we throw tons of business exceptions) only because the detailed exception message may not be shown in the UI. If it's a service, then I propagate ALL exceptions upstream. So do all systems/services in the call chain. Only the UI will decide to show or not to show but will always log all exceptions it receives. By the time the UI sees an exception, you know exactly which downstream system threw the exception and all data it received. All systems in the call chain are also employing the "Programming to Exceptions" paradigm I talk about in one of my videos. So if they (a service in the call chain) receive an exception they simply propagate that exception upstream. So in that sense, the "entry point" system (generally the back end of the UI) will see and log all exceptions. Business exceptions are displayed directly since all exception messages are business/user friendly and very useful right out of the box. For technical exceptions, messages are altered for display but the actual exception and message etc. are logged in production. In lower environments the UI will display those messages directly as well. Hope all of this makes sense? :)
One time at work i created some static classes that just received a DTO and mapped to another DTO and people told me a lot of mean stuff :). Now i create singletons and everyone is happy, as we also have a bigger test coverage %, that in reality is just a makeover, and i still ask why? Youre the first person i see questioning this. Thanks, very happy to have discovered this channel in 22, im a java person and i had to get such knowledge from a C# person :), the irony...
Would be better if you show some code, while you are talking, As beginner or not experienced with your designed system confused me little. Knowing this is Let's talk but I hope you can bring some real world code example or show some code for beginner like me, as I fear I may miss use it than what you are trying to :) . Thank you for your efforts
I would show code if I thought it was necessary :). Can you tell me what points in the video you felt seeing some code would have benefited Saurabh? That will help me better understand. FYI - the Move Service code follows these principles if you need code examples.
@@Matlus The composition part, I guess that is in facade but again it's bit confusing as I am not sure that's correct or not, that's why I am asking to pointing example from movie service project would be helpful.
@@saurabhchauhan232 Thanks for the feedback Saurabh. Composition/Aggregation are common practices in software. Any time one class uses another class it is either an aggregation or composition. So for example the Manager uses multiple classes. In that particular case it is Aggregation (But it doesn't matter for the purpose of this discussion). But look at all of the static classes in the Domain layer project and then see what classes use them and so on. That'll help (I hope) :).
As usual, I mostly agree, however I see some value in instances. As you said, testability and dependency injection is the main reason to create instances when we could simply use a static class. I think it's safe to say that most developers are used to this pattern (or more likely a general principle). It's also a royal pain to move from a static class to instances, in case some unanticipated use case forces you to do that (quick and dirty solutions, scoped services coming into play, you want to pass your object as an interface - latent polymorphism, if I want to invent a term, etc.). No refactoring tool will do that replacement for you, so you must be absolutely sure that no change is ever going to make it necessary to convert your static class into an injectable instance. On the other hand, what you gain by keeping it static is the few bytes of heap memory a single instance of that class would consume. If my object should be static, but I'm making a decision to use it as an instance because of DI, I can just register it as a singleton and forget about it.
Thank you for your well thought out comment Márton! I've moved on (so to speak) from designing for anticipation and testability to being more practical. I agree it a bit of work to go from static to instance but I've never needed to do that so far :). So given my personal experience thus far, it it happens now, it's still be ok, since the compiler will tell me exactly where I need to address things. I believe DI and testing (not testability per se) to be the "cause" rather than the reason :). As you probably know, I'm not a fan of DI and mocking or testing in isolation, so I don't see it as a benefit. But yes, I realize that DI and mocking are very common practices but their "side effects" are far reaching.
@@Matlus you won't believe this, but I've just spent about an hour doing exactly that kind of refactoring :D I had a static ConsoleHelper class that I was using extensively to create a command line experience, but then I had to make it work with redirected standard output and ITestOutputHelper (which has nothing to do with System.Console). And all this because weeks ago I made a poor design decision to just wrap some Console.WriteLine calls in static helper methods.
@@martonbalassa8128 That's great! I especially like that you recognized a bad design choice you made earlier on that lead you down a path. All too often, we get married to our choices and one bad chose leads to many others and we rarely climb up the tree to see where we went wrong and fix that which almost certainly cleans up a lot of mess. Thank you also for writing in and letting me know!
It depends on what your class is doing. If you need to verify invocations in unit tests, then you should define an interface and back it with a singleton instead. A stateless, single instance object won't degrade performance.
@@martonbalassa8128 if the test of the static methods pass, i think i don't need to mock, maybe should be a case where is a bad idea to not mock, in most scenarios i think it's ok
@@rafaelrosa3841 take the Directory and File static classes, and the system under test is some utility manipulating files and directories. You want to test if it's doing the right calls to the static classes. But you can't mock Directory and File unless you abstract all the necessary methods into an interface instead.
First of all I don't design systems for what I don't know for a fact. When you go down the route of anticipating and imagining all sorts of future possibilities you end with with a crappy and complex design and system that's very difficult to maintain. Over the years, I've just been cutting down on this "imagination and anticipation" and just designing for what I know today. Changing simple system to accommodate future growth is much easier if they're designed well. Now for your actual question :)....I think you've missed the point. only my DTO classes would get serialized. These are immutable classes that have only properties and not methods (See last weeks video). By behavior only classes are stateless and have no properties but have only methods. These are potentially static (as mentioned in this video). Have I answered your question or did I completely misunderstand your question? :)
Already looking forward to your next video - always a pleasure to listen to your videos!
Thank you Hans!
Thanks a lot for your videos. They are always well explain and with a nice tempo. I would like to know how you go about using cross-cutting concerns in your static behavioural classes without DI. Personally, I wouldn't find practical passing a logging or a context , to put an example, dependency as a parameter to the methods.
Thank you L. D. for your kind words and comments. Great question indeed.
I only log and handle exceptions in one place in my entire system. This is at the "entry point" of my applications. So in ASP.NET Core applications, I'd do this in an exception handling middleware. More specifically, my domain layer will never catch exceptions ( will happily throw lots of exceptions, however), so all exceptions will fly out (walk up the call stack) and will be caught only at the entry point.
I've never had the need, nor seen the need to log or catch exceptions in every class, method etc. Additionally, catching exceptions at the point of entry also provides access to the inputs into the system, thus that information is available to log and additionally can also be used to reproduce the issue if needed.
Hope this makes sense?
@@Matlus I agree with that approach to error handling. But I was thinking more like logging at information and warning levels (which is kind of a must on microservices applications), tracing, accessing to caches, and all the other factories and providers that are implemented in the framework. I'm cannot see how to implement these using static methods. At the other hand, there is always the possibility to create DI singletons.
@@lutfidwedari If I do have a need to log at more detailed levels (Its been over a decade since I've had that need) I'd still log at the entry point rather than all over the place in the system. If you do go the route of using an instance/singleton, I'd say you're damaging the design of your system for the sake of a "may be" :) situation.
With today's trace capabilities and (tracing between system calls) I'd have to hear a really good case to justify logging in multiple places and the damage (this causes). I think (from similar discussions with my colleagues and other architects) that there is something else my my designs and implementations (for eg. "lock the front door, lock the back door and you're safe in the house" and "Programming to Exceptions") that negates the need for logging. Or maybe it's the level/extent/style of testing my systems where in production I'm never left wondering what's going on.
I only log technical exceptions (even though we throw tons of business exceptions) only because the detailed exception message may not be shown in the UI. If it's a service, then I propagate ALL exceptions upstream. So do all systems/services in the call chain. Only the UI will decide to show or not to show but will always log all exceptions it receives. By the time the UI sees an exception, you know exactly which downstream system threw the exception and all data it received. All systems in the call chain are also employing the "Programming to Exceptions" paradigm I talk about in one of my videos. So if they (a service in the call chain) receive an exception they simply propagate that exception upstream. So in that sense, the "entry point" system (generally the back end of the UI) will see and log all exceptions. Business exceptions are displayed directly since all exception messages are business/user friendly and very useful right out of the box. For technical exceptions, messages are altered for display but the actual exception and message etc. are logged in production. In lower environments the UI will display those messages directly as well.
Hope all of this makes sense? :)
One time at work i created some static classes that just received a DTO and mapped to another DTO and people told me a lot of mean stuff :). Now i create singletons and everyone is happy, as we also have a bigger test coverage %, that in reality is just a makeover, and i still ask why? Youre the first person i see questioning this. Thanks, very happy to have discovered this channel in 22, im a java person and i had to get such knowledge from a C# person :), the irony...
Would be better if you show some code, while you are talking, As beginner or not experienced with your designed system confused me little. Knowing this is Let's talk but I hope you can bring some real world code example or show some code for beginner like me, as I fear I may miss use it than what you are trying to :) . Thank you for your efforts
I would show code if I thought it was necessary :). Can you tell me what points in the video you felt seeing some code would have benefited Saurabh? That will help me better understand. FYI - the Move Service code follows these principles if you need code examples.
@@Matlus The composition part, I guess that is in facade but again it's bit confusing as I am not sure that's correct or not, that's why I am asking to pointing example from movie service project would be helpful.
@@saurabhchauhan232 Thanks for the feedback Saurabh. Composition/Aggregation are common practices in software. Any time one class uses another class it is either an aggregation or composition. So for example the Manager uses multiple classes. In that particular case it is Aggregation (But it doesn't matter for the purpose of this discussion). But look at all of the static classes in the Domain layer project and then see what classes use them and so on. That'll help (I hope) :).
As usual, I mostly agree, however I see some value in instances. As you said, testability and dependency injection is the main reason to create instances when we could simply use a static class. I think it's safe to say that most developers are used to this pattern (or more likely a general principle). It's also a royal pain to move from a static class to instances, in case some unanticipated use case forces you to do that (quick and dirty solutions, scoped services coming into play, you want to pass your object as an interface - latent polymorphism, if I want to invent a term, etc.). No refactoring tool will do that replacement for you, so you must be absolutely sure that no change is ever going to make it necessary to convert your static class into an injectable instance. On the other hand, what you gain by keeping it static is the few bytes of heap memory a single instance of that class would consume. If my object should be static, but I'm making a decision to use it as an instance because of DI, I can just register it as a singleton and forget about it.
Thank you for your well thought out comment Márton!
I've moved on (so to speak) from designing for anticipation and testability to being more practical. I agree it a bit of work to go from static to instance but I've never needed to do that so far :). So given my personal experience thus far, it it happens now, it's still be ok, since the compiler will tell me exactly where I need to address things.
I believe DI and testing (not testability per se) to be the "cause" rather than the reason :). As you probably know, I'm not a fan of DI and mocking or testing in isolation, so I don't see it as a benefit. But yes, I realize that DI and mocking are very common practices but their "side effects" are far reaching.
@@Matlus you won't believe this, but I've just spent about an hour doing exactly that kind of refactoring :D I had a static ConsoleHelper class that I was using extensively to create a command line experience, but then I had to make it work with redirected standard output and ITestOutputHelper (which has nothing to do with System.Console). And all this because weeks ago I made a poor design decision to just wrap some Console.WriteLine calls in static helper methods.
@@martonbalassa8128 That's great! I especially like that you recognized a bad design choice you made earlier on that lead you down a path. All too often, we get married to our choices and one bad chose leads to many others and we rarely climb up the tree to see where we went wrong and fix that which almost certainly cleans up a lot of mess.
Thank you also for writing in and letting me know!
@@martonbalassa8128 one hour? Perfectly fine to me, I lost more time in misteryous runtime bug because of DI that should be get on compile time.
If the class has no state, why would you or anyone to create more expensive code(memory and CPU) to justify some future proof that can NEVER come?
It depends on what your class is doing. If you need to verify invocations in unit tests, then you should define an interface and back it with a singleton instead. A stateless, single instance object won't degrade performance.
@@martonbalassa8128 you can't test static classes/methods? Could you elaborate a real example?
@@rafaelrosa3841 You can't mock a static class (in case you need to verify invocations TO it)
@@martonbalassa8128 if the test of the static methods pass, i think i don't need to mock, maybe should be a case where is a bad idea to not mock, in most scenarios i think it's ok
@@rafaelrosa3841 take the Directory and File static classes, and the system under test is some utility manipulating files and directories. You want to test if it's doing the right calls to the static classes. But you can't mock Directory and File unless you abstract all the necessary methods into an interface instead.
what if we cannot anticipate the need for serialization ? wouldn't it be better to include all classes non static.
thanks,
Vishnu
First of all I don't design systems for what I don't know for a fact. When you go down the route of anticipating and imagining all sorts of future possibilities you end with with a crappy and complex design and system that's very difficult to maintain. Over the years, I've just been cutting down on this "imagination and anticipation" and just designing for what I know today. Changing simple system to accommodate future growth is much easier if they're designed well.
Now for your actual question :)....I think you've missed the point. only my DTO classes would get serialized. These are immutable classes that have only properties and not methods (See last weeks video). By behavior only classes are stateless and have no properties but have only methods. These are potentially static (as mentioned in this video).
Have I answered your question or did I completely misunderstand your question? :)
@@Matlus thank you for clarification sir. I had missed your point. Thanks for spending your valuable time for this long comment..
@@vishnupv2008 not a problem at all.