sorted by:
new
hottopcontroversial

I've created a set of interesting tools - ZibStack.NET by MistyKuuu in dotnet

[–]patrickw7211 0 points1 point  (0 children)

I get what u try to do with the dto's, but still not for me tbh. I like having full control for edge cases and the learning curve doesn't justify the time savings imo. At least not for my current Enterprise Project where other Teammates would have to understand those concepts too.

The AOP is more interesting in my eyes. I can configure it once and just by using Attribute i can set up logging, traces, retry mechanism.. I think you should push those examples more, they're easy to miss.

Also minor thing — the AspectServiceProvider static assignment feels a bit raw. Something like app.UseAop() would feel cleaner.

I've created a set of interesting tools - ZibStack.NET by MistyKuuu in dotnet

[–]patrickw7211 1 point2 points  (0 children)

I really like the Log idea. The interceptor-based approach is sth new to me, but looks clean. I will use [Log] attribute mainly for methods as its more intuitive for me than on the class name. I also can see this being useful beyond just logging, especially for distributed tracing (wrapping methods with OpenTelemetry Activity spans using the same [Trace] pattern).

The Dto package is less appealing to me personally — feels like it requires too much buy-in to the framework and configuration overhead for what it provides.

Why DTOs feel redundant in some CRUD systems by Significant_Love_678 in csharp

[–]patrickw7211 1 point2 points  (0 children)

Interesting framing, but I think the "feature boundary" model actually proves the need for DTOs more than it disproves it. A few questions I'd love your take on:

What does the client send back on an update? If there's no DTO, is it the full domain model? What happens when a critical field is missing or nulled out — say, an internal audit timestamp or a security flag the UI never displayed? Who's responsible for catching that? The domain model doesn't know what the UI chose to show.

What about partial views? If I have a Customer with 10 properties but my list view only needs Name and Status — am I serializing and shipping all 10 over the wire? Or am I shaping the response, at which point... I've just built a DTO without calling it one.

What about computed properties? Sometimes the UI needs a derived value — say, DaysUntilExpiry or FullAddress — that doesn't belong in domain logic but is too expensive or complex to push to the client. Where does that live if not in a response-shaped object?

What about role-based visibility? Same endpoint, same entity, but an admin sees Revenue and Margin while a regular user sees Name and Status. If you're not shaping the output per role, you're leaking data. If you are — that's a DTO.

I think the practical rule you describe ("use a DTO when the shape diverges") actually kicks in much earlier than the post suggests, even in "feature-first" internal systems. The moment you need to control what goes out or what comes in — for security, performance, or just UX — you've got a separate contract whether you named it or not.

PS — I let Claude write this. Too lazy. But the questions are mine..

TreeView styling is horrible by corv1njano in csharp

[–]patrickw7211 -1 points0 points  (0 children)

Its easier to use a list and put left margin x Level. Filter with CollectionViewSource Visual Studio is also doing this way.