4 ms·

Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them. React is the

Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them. React is the other way around. Routing in React seems to be an afterthought. And I hate it with a passion. Page based way of thinking (or "screens" if you will) is a better way to do web dev. Also, the Dependency Injection system is extremely productive. State management in Blazor is very easy and a breeze to use. If not for the intricacies of hosting models, and a slightly large default build size for the full WASM client mode, Blazor would have replaced React / Angular / Vue by now.

starik36 5y ago
> Dependency Injection system is extremely productive Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.
- deleted 5y ago
  [deleted]
- kumarvvr 5y ago
  Sorry, if tests are not adaptable to changing code, why are they called tests? I thought tesring was to check software,not be a constraint on software development. Also, I think using DI in the test process itself will mitigate the issue.
  - spaetzleesser 5y ago
    Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor. It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.
    - culturedsystems 5y ago
      Constructor inject is generally a positive here, though, as the compiler will tell you where you need to add the new dependency. If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.
      - spaetzleesser 5y ago
        “If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.” Sure in theory this is correct but you can’t always anticipate future needs. The class may still have very clearly defined responsibility but it just needs another piece of information that you can get only with DI. I feel this over dependence on DI in .NET forces you to design around the framework and not around what makes sense.
- infogulch 5y ago
  I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. Unit test setup starts by getting a new instance and overriding the mocks that it cares about. Now constructor breakage is isolated to fixing the default mocks in the helper method. Maybe I should write this up somewhere.
  - spaetzleesser 5y ago
    I did that too and it should be the default. Constructor injection is a bad pattern.
    - infogulch 5y ago
      What do you mean by "constructor injection"?
      - spaetzleesser 5y ago
        In .NET a lot of DI is done by adding another interface to the constructor. So if you need some service way down the stack you add it to the constructor. This then in turn can require adding this dependency to all the tests that use this service.
        infogulch 5y ago
        My comment describes a way to organize unit tests to work around this issue.
        Van-Dame 5y ago
        Comments like these really amaze me. What sort of competent editor cannot handle such simple refactorings?
        hackerfromthefu 5y ago
        Maybe but in Blazor you have the choice of Property or Constructor DI. This choice is in all the major DI container libraries I've worked with in .NET, around a dozen over the years.
- spaetzleesser 5y ago
  I have seen that too. They do way too much DI.
- Merad 5y ago
  We use a tool called AutoFixture to automatically generate objects being tested. It will automatically mock constructor dependencies, so a change like you described doesn't require any test changes unless the new mock requires some setup for the test to pass.

starik36 5y ago

> Dependency Injection system is extremely productive Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.

deleted 5y ago
[deleted]
kumarvvr 5y ago
Sorry, if tests are not adaptable to changing code, why are they called tests? I thought tesring was to check software,not be a constraint on software development. Also, I think using DI in the test process itself will mitigate the issue.
- spaetzleesser 5y ago
  Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor. It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.
  - culturedsystems 5y ago
    Constructor inject is generally a positive here, though, as the compiler will tell you where you need to add the new dependency. If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.
    - spaetzleesser 5y ago
      “If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.” Sure in theory this is correct but you can’t always anticipate future needs. The class may still have very clearly defined responsibility but it just needs another piece of information that you can get only with DI. I feel this over dependence on DI in .NET forces you to design around the framework and not around what makes sense.
infogulch 5y ago
I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. Unit test setup starts by getting a new instance and overriding the mocks that it cares about. Now constructor breakage is isolated to fixing the default mocks in the helper method. Maybe I should write this up somewhere.
- spaetzleesser 5y ago
  I did that too and it should be the default. Constructor injection is a bad pattern.
  - infogulch 5y ago
    What do you mean by "constructor injection"?
    - spaetzleesser 5y ago
      In .NET a lot of DI is done by adding another interface to the constructor. So if you need some service way down the stack you add it to the constructor. This then in turn can require adding this dependency to all the tests that use this service.
      - infogulch 5y ago
        My comment describes a way to organize unit tests to work around this issue.
      - Van-Dame 5y ago
        Comments like these really amaze me. What sort of competent editor cannot handle such simple refactorings?
      - hackerfromthefu 5y ago
        Maybe but in Blazor you have the choice of Property or Constructor DI. This choice is in all the major DI container libraries I've worked with in .NET, around a dozen over the years.
spaetzleesser 5y ago
I have seen that too. They do way too much DI.
Merad 5y ago
We use a tool called AutoFixture to automatically generate objects being tested. It will automatically mock constructor dependencies, so a change like you described doesn't require any test changes unless the new mock requires some setup for the test to pass.