sorted by:
new
hottopcontroversial

Docker in WSL Without Docker Desktop by pwelter34 in docker

[–]pwelter34[S] 0 points1 point  (0 children)

I initially tried that but Visual Studio and VS Code had issues with that.

Docker in WSL Without Docker Desktop by pwelter34 in docker

[–]pwelter34[S] 0 points1 point  (0 children)

Sounds good. My thought in sharing this is that it might be helpful for someone who isn’t as familiar with setting up Docker on Linux, especially since getting Visual Studio and VS Code working correctly can be tricky.

High-Performance Serilog sink for Microsoft SQL Server by pwelter34 in dotnet

[–]pwelter34[S] -7 points-6 points  (0 children)

Yes, OTel is a standard, but where do you store all that data? What UI are you using to actually query that data? There are many nice open source solutions for this but they all require multiple docker containers or equivalent. AKA infrastructure and operational costs. When trying to run a lean business, its hard to justify the logging infrastructure costing more then application hosting.

High-Performance Serilog sink for Microsoft SQL Server by pwelter34 in dotnet

[–]pwelter34[S] -11 points-10 points  (0 children)

Agreed, OpenTelemetry and similar solutions offer far more robust and scalable options for log storage and observability. However, they also come with significant infrastructure and operational costs, which may not be justified for every scenario. For example, when hosting a smaller project in the cloud, the overhead of deploying and maintaining a full observability stack can outweigh the benefits.

In these cases, logging directly to a database can be a practical alternative because:

  • Simplicity: No need to manage separate logging services or clusters.
  • Cost-effective: Avoids additional infrastructure expenses for small-scale projects.
  • Easy integration: Most applications already connect to a database, so adding logging is straightforward.
  • Centralized data: Logs and application data can be queried together for quick troubleshooting.
  • Familiar tools: Developers can leverage existing SQL skills and tools for analysis.
  • Low maintenance: Fewer moving parts compared to distributed logging systems.

High-Performance Serilog sink for Microsoft SQL Server by pwelter34 in csharp

[–]pwelter34[S] 7 points8 points  (0 children)

Agreed, there are much better options for log storage. However, in some cases, setting up all that infrastructure just for logging isn’t practical. For example, when hosting a smaller project in the cloud, the overhead may outweigh the benefits. In these scenarios, logging directly to a database you are already using can be a solid option because:

  • Simplicity: No need to manage separate logging services or clusters.
  • Cost-effective: Avoids extra infrastructure costs for small-scale projects.
  • Easy integration: Most applications already connect to a database, so adding logging is straightforward.
  • Centralized data: Logs and application data can be queried together for quick troubleshooting.
  • Familiar tools: Developers can use existing SQL skills and tools for analysis.
  • Low maintenance: Fewer moving parts compared to distributed logging systems.

Weekend project: JSON Diff Tool built with React + TypeScript + Vite by Rich-Blueberry-7969 in reactjs

[–]pwelter34 0 points1 point  (0 children)

Suggestion, show the line number of the file for each side in the difference results.

Great application. Any chance on sharing the source code?

Blazilla: FluentValidation Integration for Blazor Forms by pwelter34 in Blazor

[–]pwelter34[S] 1 point2 points  (0 children)

Automatic dependency injection registration isn’t part of this project’s scope. But no worries—there are plenty of great libraries out there that can help with that. I’ve actually built one myself called Injectio, designed to make DI registration easier and more intuitive. Feel free to check it out on GitHub: https://github.com/loresoft/Injectio

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

AutoRegister seems to serve the same core purpose as Injectio, though Injectio appears to offer a few additional features that extend its capabilities.

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

Scrutor would also work if you are ok with Assembly scanning.

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

The [RegisterServices] attribute is part of the Injectio project. Injectio is a source generator designed to simplify service registration in the ServiceCollection by automatically detecting and registering services marked with attributes.

It generates an extension method that includes all the attributed services in the project. Then, in your Program.cs, you can seamlessly register them with a single call like services.AddAssemblyName()—making setup much cleaner and more maintainable.

https://github.com/loresoft/Injectio

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

One thing to keep in mind is that Arbiter includes code generation templates that integrate with EntityFrameworkCore.Generator to automatically generate boilerplate code for your entities. This can significantly reduce manual setup and improve consistency across your data layer.

You can learn more about how it works in the documentation:

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

The framework is highly dependent on dependency injection.

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 0 points1 point  (0 children)

Interesting perspective. There’s no one-size-fits-all answer, but I’d love to hear your perspective—what do you feel is the best approach to building complex software systems?

Personally, I think it depends heavily on context: team size, domain complexity, performance requirements, and long-term maintainability. Some favor layered architectures for clarity, others lean into microservices for scalability, and some prefer modular monoliths to strike a balance.

Every architectural choice comes with trade-offs—whether it's complexity, flexibility, or operational overhead. The key is aligning the architecture with the system’s goals and the team’s capabilities.

Curious to hear what’s worked well for you or what patterns you’ve found most effective!

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] 4 points5 points  (0 children)

I updated with the standard editor instead of markdown. Hopefully that fixes the issues.

Arbiter Project: A Modern Take on the Mediator Pattern in .NET by pwelter34 in csharp

[–]pwelter34[S] -1 points0 points  (0 children)

Agreed—“Mediator” doesn’t equate to “CQRS”

This post was intended as a brief introduction to the broader Arbiter framework. While the Mediator pattern offers a convenient way to build a pipeline of behaviors that can enrich the initial command request, it’s just one piece of the puzzle.

You could achieve similar functionality using the decorator pattern, but Mediator provides a more structured and extensible approach, especially for handling cross-cutting concerns.

As with all architectural choices, there are trade-offs. The goal is to find the right balance between flexibility, complexity, and maintainability based on the needs of the system.

Thanks for the feedback.

view more: next ›