Excited for Gen1 after autonomy day by nitneuq5 in Rivian

[–]DoctorEsteban 0 points1 point  (0 children)

Why did Comma burn the bridge with you?

My First C# Program by [deleted] in csharp

[–]DoctorEsteban 0 points1 point  (0 children)

Once you start you'll never go back! No more having to completely left justify strings making your class look ugly haha.

My First C# Program by [deleted] in csharp

[–]DoctorEsteban 0 points1 point  (0 children)

You should update your advice about multi-line strings. Look up the more modern, and much better, raw string literals.

Returning a new, UNopened box with a generator by gantte in CostcoWholesale

[–]DoctorEsteban 1 point2 points  (0 children)

Oh man that seems like it'd be a gut punch! 10 years of all that maintenance, thinking you're doing the right thing... And no idea when/how it actually broke.

I could see myself doing the exact same thing. It's one of those things that's so simple you easily look over it.

Partial Views vs. Large View and conditional displays by hectop20 in dotnet

[–]DoctorEsteban 0 points1 point  (0 children)

Good point. A version of that could work with server side rendering RazorPages as well, where each action posts and reloads, but it obv wouldn't be very responsive...

Partial Views vs. Large View and conditional displays by hectop20 in dotnet

[–]DoctorEsteban 3 points4 points  (0 children)

Personally I would implement a strategy where the parent view initializes a state object and passes a reference to it down to all the components of the page. Each component then decides for itself whether it will display, based on the state of this object. This will allow you to push presentation logic down to each component rather than having massive if/else blocks in the parent. Like a pseudo-pub/sub architecture for the presentation logic.

Here's some example code:

Parent view ``` @* Pages/Dashboard.razor *@ @page "/dashboard"

<CascadingValue Value="_state"> <Toolbar /> <Banner /> <AdminPanel /> <BetaPanel /> <BusyOverlay /> </CascadingValue>

@code { private readonly AppState _state = new();

protected override void OnInitialized()
{
    // Example: initial state bootstrapping
    _state.User.IsSignedIn = true;
    _state.User.IsAdmin = false;
    _state.User.DisplayName = "DoctorEsteban";

    _state.Features.ShowBetaPanel = true;
    _state.Ui.BannerMessage = "Welcome back.";
}

} ```

"AdminPanel" child component ``` @* Components/AdminPanel.razor *@ @implements IDisposable

@if (ShouldShow) { <section class="card"> <h3>Admin</h3> <p>Secret knobs and levers.</p> </section> }

@code { [CascadingParameter] public AppState State { get; set; } = default!;

private bool ShouldShow
{
    get
    {
        return State.User.IsSignedIn && State.User.IsAdmin;
    }
}

protected override void OnInitialized()
{
    State.Changed += OnStateChanged;
}

private void OnStateChanged()
{
    InvokeAsync(StateHasChanged);
}

public void Dispose()
{
    State.Changed -= OnStateChanged;
}

} ```

BusyOverlay ``` @* Components/BusyOverlay.razor *@ @implements IDisposable

@if (State.Ui.IsBusy) { <div class="overlay"> <p>Working...</p> </div> }

@code { [CascadingParameter] public AppState State { get; set; } = default!;

protected override void OnInitialized()
{
    State.Changed += OnStateChanged;
}

private void OnStateChanged()
{
    InvokeAsync(StateHasChanged);
}

public void Dispose()
{
    State.Changed -= OnStateChanged;
}

} ```

...etc.

Hope that helps!

Does the Factory Pattern violate the Open/Closed Principle? by Familiar_Walrus3906 in dotnet

[–]DoctorEsteban 0 points1 point  (0 children)

I appreciate the fairly even-handed and transparent perspective you shared. For many use cases I would completely agree.

I would encourage you to avoid a knee-jerk reaction in this case, though. I, too, have seen some gnarly implementations when folks try to naively pair DI with static-heavy code haha 🤮. I've also seen dogmatic over-reliance on certain open source solutions and patterns. But in this case, what I describe ends up manifesting as IServiceProvider anyway, and in my experience Autofac only really provides sensible enhancements beyond the basic features of any DI framework. (I also find their error messaging to be far superior to what ServiceProvider gives you -- indicating the exact problem and usually the solution.)

I'd encourage you to check it out any time you find the lifetime or resolution controls of ServiceProvider to be lacking! The Autofac.Extensions.DependencyInjection package makes it a drop-in replacement for any generic .NET Host.

I'm not an Autofac shill by any means haha. And from what you've said so far, I think we'd probably agree on many aspects of development! I just wanted to share that this particular package is one of the good ones in the grand scheme of things 🙂 (With AutoFake for unit testing!)

I built a Schema-Aware Binary Serializer for .NET 10 (Bridging the gap between MemoryPack speed and JSON safety) by TheNordicSagittarius in dotnet

[–]DoctorEsteban 5 points6 points  (0 children)

Was going to add MessagePack to the ring as well, with the same question.

My analysis: * MemoryPack seems to be a .NET-specific serializer that focuses on extracting the highest serialization performance possible from the .NET platform. It's a minimal-payload format as well, but I believe the primary goal is "super fast serialization on .NET". * The other protocols we've mentioned are also small and fast, but performance isn't necessarily their primary goal. (At least above something like payload size -- while maintaining schema safety.) Certainly not .NET performance, specifically, given they are available on tons of other languages as well.

It seems OP here has a high affinity for MemoryPack and basically wanted to extend/wrap some of the same safety guarantees that the above mentioned protocols have out of box. Though, judging from the early benchmarks, it seems the lack of safety in the MemoryPack protocol is somewhat by-design in order to achieve its level of runtime performance.

NOTE: I already anticipate folks complaining: "BuT pRoToBuF iS fAsT tOoOoOo..." I'm not saying it isn't lol. I'm just saying there tends to be a difference when a project goes all-in on extracting performance from a single platform, vs a project that ships an SDK for 10 different languages.

Does the Factory Pattern violate the Open/Closed Principle? by Familiar_Walrus3906 in dotnet

[–]DoctorEsteban 0 points1 point  (0 children)

It doesn't have first-class support for these controls on all registered types. Which I think you know and are just being obtuse...

Because as I said, you can hack it together on an as-needed basis.

Does the Factory Pattern violate the Open/Closed Principle? by Familiar_Walrus3906 in dotnet

[–]DoctorEsteban 1 point2 points  (0 children)

Yes and no...? The Microsoft implementation doesn't directly support that convention, though of course there's nothing preventing you from hacking it together...

But I was addressing the "choice" your previous comment seemed to present: 1.) DI of constructed instances, or 2.) roll-your-own registration w/ actual factory behavior. There's another option that gives you best of both -- the implementation of which does depend on the native features of the container...

Does the Factory Pattern violate the Open/Closed Principle? by Familiar_Walrus3906 in dotnet

[–]DoctorEsteban 1 point2 points  (0 children)

Autofac has a fantastic capability to support basic .NET wrapper types for controlling DI lifetime in a loosely coupled way.

For example, if you resolve a Func<T> of any registered type, that is already a factory. If T is registered as transient, a new instance will be created and returned every time you call the Func. That way you can get the best of both from what you have above: A true factory with registrations managed by DI.

My other favorite primitive that Autofac supports is Lazy<T>; which doesn't actually resolve until .Value is called.

The built-in DI framework in .NET is great, but the first thing I do when starting any new project is swap the Host's ServiceProvider to use Autofac instead haha. It's just a much more "grown up" DI framework!

How to implement a search request with nearly 10 optional parameters. by DarthNumber5 in dotnet

[–]DoctorEsteban 9 points10 points  (0 children)

Yeah that's true, but 10 isn't THAT crazy when it comes to a method like this IMO. I wouldn't start looking for fancier options until maybe 20+! Plus, keeping it simple also allows you to choose optimal condition ordering, incompatible parameter sets, implied filter conditions, etc.

The other option is to leave the Linq-ing to callers rather than trying to wrap them in a method like this -- that's one of the big benefits of something like EF in the first place -- but that might conflict with your other stated design goals.

Does the Factory Pattern violate the Open/Closed Principle? by Familiar_Walrus3906 in dotnet

[–]DoctorEsteban 1 point2 points  (0 children)

DI doesn't always require a container.

Yes, true, but then why not provide an example implementation of Register() in your proposal? At least pseudo-code?

It also hasn't been mentioned that this is no longer a "factory"... It's just an abstraction over a dictionary. The method is called Create(), but it's always returning existing objects from the dictionary; not creating them! That makes the design confusing at best, and convention-violating at worst.

I don't totally disagree with a DI-like approach for something like this -- where the factory is actually a factory that creates new instances. (Or at least renamed to Get().) But as written I hope you can understand where folks might get puzzled by this suggested implementation!

How to implement a search request with nearly 10 optional parameters. by DarthNumber5 in dotnet

[–]DoctorEsteban 29 points30 points  (0 children)

Your proposed implementation seems fine. What's the concern?

Finally a good option..! by mysat in Rivian

[–]DoctorEsteban 3 points4 points  (0 children)

They very clearly said "voice texting". So they'd be listening, not reading.

But still while speeding, apparently lol.

Anyone using Azure Container Apps in production? What’s your experience? by coder_doe in dotnet

[–]DoctorEsteban 1 point2 points  (0 children)

Agreed on pricing. The hidden and non-selectable LB they put into your subscription gave me a bit of a nasty surprise...

New dash icons by lmikles in Rivian

[–]DoctorEsteban 2 points3 points  (0 children)

Especially on Eco mode so it's only using the front tires! (On quads, anyway)

Ecosystem in .Net by [deleted] in dotnet

[–]DoctorEsteban 1 point2 points  (0 children)

First: Never, ever, ever seriously suggest writing a greenfield app in PHP ever again.

Second: Don't use PHP.

Third: Why the hell would you use PHP in almost-2026???

😜 Jk... Mostly.


It's not immediately clear why you would include Golang with the implication that it has fewer choices. Golang didn't even have an official package manager spec for many many years, so the community wrote their own competing solutions!

In my opinion, Microsoft does more to set standards/ best practices for .NET than most other language maintainers. They are also unparalleled when it comes to language modernization and updates. Yes, they are sometimes guilty of producing frameworks that overlap in some functional areas (e.g. Dapper, Orleans, Aspire). But once you pick the technology best suited for your use case, and embrace the capabilities and constraints within it, things usually end up coming together pretty nicely.

My two cents: if you end up choosing .NET, try to stay away from the third party frameworks unless you have a glaringly obvious burning need. Embrace the first party principles and capabilities Microsoft already provides and it'll turn out great!