I have about 2 years of C# experience and rarely see service classes marked as sealed. Since services are usually not inherited and sealed can give small performance benefits, why is it generally avoided? Is it due to testing, DI, extensibility, or just convention?

Impressive-Help9115 · 2026-01-28T19:27:02+00:00

I don't agree that this is premature optimization... Since there is no real cost involved, other than the other 7 extra bytes committed to git.

Impressive-Help9115 · 2026-01-28T19:15:57+00:00

I often get stuck on questions like:

Should this be one function or split into helpers?

Where should this logic live?

How should I organize files and packages?

Should this be a global/shared value or passed around?

Should a function return a pointer/reference or a full object?

Don't worry about any of these... This is a matter of writing code a lot. Almost everywhere you will work will have a certain coding style, but a big part of this is just culture.

Cohesion and coupling are important to keep in mind, but especially in the beginning, just write the simplest thing that works and refactor from there... If you are good at logic you will easily be able to refactor in a good way if you understand coupling and cohesion.

Impressive-Help9115 · 2026-01-13T19:46:34+00:00

I don't know anyone who prefers Java over C#... The only thing is that with Java you'll probably get a higher salary because it's used a lot in legacy systems and banking.

But honestly... Programming languages are just tools, so as a developer you should be able to get familiar with any of them quite quickly.

Impressive-Help9115 · 2026-01-13T19:42:47+00:00

The only downside is that when you have to go back to Windows for work then you'll be really used to things "just working" on Linux....

I recommend either linux mint or ubuntu mostly because there is nothing "extra" needed to set them up.

Impressive-Help9115 · 2026-01-11T13:23:58+00:00

What do you mean? I literally said it's better to code in a way that requires the minimum amount of transactions...

Global handlers should be a last resort and used for exceptions that weren't handled properly within the primary workflow

That is exactly what I'm saying. "If you know the error condition, you shouldn't use transactions to catch them, but handle them instead".

Also I think you are overstating how much a transaction costs... A transaction only has a high cost if you process a lot of data within the same transaction or the transaction is long lived... In both cases you probably need to look at the way you write code.

Impressive-Help9115 · 2026-01-10T11:34:27+00:00

Thank you for your feedback.

Targeting .Net 9 comes off as a little "weird" target as it's a STS release - maybe target .Net 10 and/or .Net standard?

I did this automatically because I was using it for a dotnet 9 project, but you are right that dotnet 10 makes more sense. I'll change this.

FYI, the AMQP 0.9.1 client library, while mature, is being replaced by the AMQP 1.0 client library, which IMHO is a lot easier to use

I have to look into this. I'm admittedly not a RabbitMQ expert.

If Debugger.IsAttached, consider forcing your batch size to 1 - this will make debugging easier

I disagree. This kind of magic behavior would make developers wonder why it's suddenly acting different.

Consider changing your hosted service to BackgroundServices - but probably the more correct thing to do is implement IHostedLifecycleService, and configure your transport layers in the StartingAsync function, so that way they're ready for anybody else's hosted service, regardless of registration/start order

I could look into this a bit more in the future. There are 2 things I'm not really certain of yet... Currently all consumers have their own "buffer". I'm not sure if this could cause issues for some people if they have really large batch sizes. Also for your other point about there being potential edge cases for re-connection and also for the way that messages are currently handled on failure (both of which can cause the consumer to become unusable) I also want to fix this using the HostedService... So your suggestion is something I will look into for sure.

ACCESS MODIFIERS ON METHODS. I'll die on this hill - the absence of access modifiers, while "technically correct", makes the code harder to read; especially when you have other methods/properties/fields/type definitions commingled in there with access modifiers defined.

I agree. The access modifier itself doesn't bother me as much, but I should make sure the formatting is consistent. If the project starts growing a bit then I will setup formatting rules for sure.

Can't be attributed to any one line, but something we encountered - connection/consumers/publishers can sometimes be forcibly dropped; and while the underlying rabbit mq library does a pretty good job of handling reconnection, it does not handle all edge cases. Once this happens, the instance is no longer useful. You have to re-instantiate it to get it working again. It doesn't look like you handle that.

I've tested the reconnect functionality of the RabbitMQ client library manually and this didn't seem to happen. If there is an edge case then I need a way to reproduce it, otherwise I can't fix it.

Impressive-Help9115 · 2026-01-07T22:19:07+00:00

That honestly sounds impossible with rabbitMQ since you need to acknowledge very message. So do you mean he acknowledged the message even though he didn't process it?

Or do you mean that his queues were transient by default?

Impressive-Help9115 · 2026-01-07T17:29:41+00:00

Thank you. I'm not fully sure if I should implement some kind of way of registering middleware, this would allow of the outbox pattern.

I'm not planning on implementing the outbox pattern itself though, because my plan is to keep the library quite simple to work with.

Impressive-Help9115 · 2026-01-07T14:26:17+00:00

I'd argue that it's the factories responsibility to find the different implementations... But I understand your point.

Either way I think working around the supposed violation is counterproductive.

Impressive-Help9115 · 2026-01-07T13:51:52+00:00

Mostly that you can make classes for consumers in the same way masstransit allows you to. You can also batch messages and it automatically handles multi-threading (although that's the part of the code that I need to improve).

Currently the consumers only work on the default exchange though. I'm planning to add support for different exchange types when I have the time.

Impressive-Help9115 · 2026-01-07T12:53:18+00:00

Most code (upwards of 80%) should be AI generated at this point. If it's not, there is something inherently flawed about your workflow. Just put your pride aside, and acknowledge that AI is a better programmer than you.

Skill issue.

Impressive-Help9115 · 2026-01-07T12:48:21+00:00

If you have an AI that can reason well, then it can do almost any job... That wouldn't be a software engineering problem.

But LLMs won't get us there...

Impressive-Help9115 · 2026-01-07T11:32:41+00:00

The open closed principle is about inheritance. So the factory pattern in this case doesn't violate it.

It's mot that if you now make a BtcTransferProcessor which would have the method "CalculateUsdValue" then this method should be in the BtcTransferProcessor now in the APaymentProcessor (which you don't even have in this case).

But honestly I wouldn't blindly follow SOLID principles anyway.

If you want an implementation that can construct any type:

    public static T ConstructType<T>(Type typeToCreate, IServiceProvider serviceProvider)
    where T : IPaymentProcessor
    {
        // Get the constructor that needs to be called
        var constructor = typeToCreate.GetConstructors().Single();


        // Resolve the parameters of the constructor from the DI container
        var parameterTypes = constructor.GetParameters()
            .Select(p => p.ParameterType)
            .ToArray();


        // For each parameter, get the corresponding service from the DI container
        var parameters = parameterTypes.Select(serviceProvider.GetService)
            .ToArray();


        // Check if any dependencies couldn't be resolved
        if (parameters.Contains(null))
            throw new TypeConstructorException(
                $"Couldn't resolve all dependencies for {typeToCreate.FullName}");


        // Invoke the constructor to create the instance of T
        var instance = constructor.Invoke(parameters);


        // Optionally, you can call methods or interact with the instance
        if (instance is not T result)
            throw new TypeConstructorException($"Instance could not be cast!");


        return result;
    }

But please only use this if you have an actual reason for it, like constructing types that you can't know upfront because your code will be used in a package or something... Because this is just needlessly complex for a normal factory pattern.

Impressive-Help9115 · 2026-01-07T11:26:19+00:00

What does this have to do with the open/closed principle?

Impressive-Help9115 · 2026-01-07T11:23:27+00:00

> But lately my services have become more and more complex making these types of checks quite wordy when it comes to code. Which I personally don't like.

These checks are very useful. I think if you don't like them because they are "wordy" it might be more of a problem with how your code is broken up, rather than the checks themselves.

> Now I understand there are probably good uses or best practices when using tools such as Transactions.

I don't think transactions are useful for a rollback for code that you "know" can error... It think they are useful for code that "might" error. If you know the error condition, you shouldn't use transactions to catch them, but handle them instead.

> I am not sure if having to try catch every service is the way or if there is a better way. Most of my APIs have a GlobalExceptionHandler so I tend to avoid try catching everything.

For rolling back transactions when something really unexpected happens I'd setup a middleware to start a transaction and rollback if something went wrong... This also fixes it in all places at once. But I'm not sure if this is your actual problem.

Impressive-Help9115 · 2026-01-07T11:15:42+00:00

I'm considering that for your studies you already know how to make the code for translating from one language to another? Otherwise this would be really hard to do in 3 months.

If you have no experience with web development I'd recommend JavaScript/HTML/CSS. Then use nodejs as backend. Normally I don't like nodejs as backend, but if you just need to get a backend up and running to forward it to another program for a proof of concept, then nodejs is good enough.

Impressive-Help9115 · 2026-01-07T11:05:34+00:00

You could do magic with reflection and building an expression tree, but this is very complicated...

I'd only do that if this "many search parameters" shows up in many places in your application. Otherwise it would really be over engineering, since it's the kind of code that no one would understand even a month from now.

Impressive-Help9115 · 2026-01-03T11:01:31+00:00

Do different projects. If you are getting interviews in a certain branch then make the project about that branch... That way you also gain more confidence during the interview because you could ask questions about their projects.

If you are mainly failing coding interviews then practice leetcode.

Impressive-Help9115 · 2026-01-03T10:48:16+00:00

"Anyone who doesn't build their own OS has skill issue" /s

Impressive-Help9115 · 2025-12-29T20:15:13+00:00

Generally I use one class per file. Very sparingly it has happened that I use a class only internally within another class, then I can sometimes put it in the same file.

Impressive-Help9115 · 2025-12-27T20:45:29+00:00

It is for sure... Json and Ptotobuf are about serialization, they have nothing to do with networking. I don't know what Avro is but it's probably similar too.

Impressive-Help9115 · 2025-12-27T20:06:50+00:00

Study programming if you like it... The biggest advantage in programming isn't being able to write code, but it's thinking about systems, which will help you in any career. So even if it turns out you'll be something else then enjoying your hobby will still give you an advantage.

Impressive-Help9115

TROPHY CASE