Return to Answer

• A decorator pattern. Take a look at how streams are organized. How you can wrap a buffering stream around a file stream to get a file stream with a large buffer. Don't you think that, for example, encryption can be added to existing connection by wrapping around it? It will require a change in signature, but maybe it is a good thing?
• A pipeline pattern. Why should connection know every step which needs to be taken to process a message. First decrypt it, then create reader, then pass a handler, then continue processing inside a handler... That sounds like a pipeline to me. Wouldn't it be nicer if your connection was only responsible for reading an array of bytes? Once you have the binary packet you could just pass it to some IMessagePipeLine.Process(byte[]) method. Or maybe just fire some event Action<byte[]> PacketReceived and let the outer code handle the data? P.S. If you are interested in this approach check out TPL.Dataflow library, it has some neat classes for building an async pipeline, and I believe it is available under .Net Core.

• A decorator pattern. Take a look at how streams are organized. How you can wrap a buffering stream around a file stream to get a file stream with a large buffer. Don't you think that, for example, encryption can be added to existing connection by wrapping around it? It will require a change in signature, but maybe it is a good thing?
• A pipeline pattern. Why should connection know every step which needs to be taken to process a message. First decrypt it, then create reader, then pass a handler, then continue processing inside a handler... That sounds like a pipeline to me. Wouldn't it be nicer if your connection was only responsible for reading an array of bytes? Once you have the binary packet you could just pass it to some IMessagePipeLine.Process(byte[]) method. Or maybe just fire some event Action<byte[]> PacketReceived and let the outer code handle the data? P.S. If you are interested in this approach check out TPL.Dataflow library, it has some neat classes for building an async pipeline, and I believe it is available under .Net Core.

• A decorator pattern. Take a look at how streams are organized. How you can wrap a buffering stream around a file stream to get a file stream with a large buffer. Don't you think that, for example, encryption can be added to existing connection by wrapping around it? It will require a change in signature, but maybe it is a good thing?
• A pipeline pattern. Why should connection know every step which needs to be taken to process a message. First decrypt it, then create reader, then pass a handler, then continue processing inside a handler... That sounds like a pipeline to me. Wouldn't it be nicer if your connection was only responsible for reading an array of bytes? Once you have the binary packet you could just pass it to some IMessagePipeLine.Process(byte[]) method. Or maybe just fire an event? P.S. If you are interested in this approach check out TPL.Dataflow library, it has some neat classes for building an async pipeline, and I believe it is available under .Net Core.

1. What is this infinite loop doing inside your program class? Apart from periodically stealing processor core from other threads? Why not run your listener inside the main thread synchronously?

2. There is no clean up on Program close. Connections are never terminated and DI container is never disposed.

3. _handler.Handle(this, reader); - this should rise red flags. Circular dependencies are almost always an indication of some poor design choices. So whenever you have to pass a this reference to a method, try to figure out why it is necessary. Maybe instead what you actually need is another service, that both classes ("handler" and "connection") can depend on.

• A decorator pattern. Take a look at how streams are organized. How you can wrap a buffering stream around a file stream to get a file stream with a large buffer. Don't you think that, for example, encryption can be added to existing connection by wrapping around it? It will require a change in signature, but maybe it is a good thing?
• A pipeline pattern. Why should connection know every step which needs to be taken to process a message. First decrypt it, then create reader, then pass a handler, then continue processing inside a handler... That sounds like a pipeline to me. Wouldn't it be nicer if your connection was only responsible for reading an array of bytes? Once you have the binary packet you could just pass it to some IMessagePipeLine.Process(byte[]) method. Or maybe just fire some event Action<byte[]> PacketReceived and let the outer code handle the data? P.S. If you are interested in this approach check out TPL.Dataflow library, it has some neat classes for building an async pipeline, and I believe it is available under .Net Core.

1. What is this infinite loop doing inside your program class? Apart from periodically stealing processor core from other threads? Why not run your listener inside the main thread synchronously?

2. There is no clean up on Program close. Connections are never terminated and DI container is never disposed.

3. _handler.Handle(this, reader); - this should rise red flags. Circular dependencies are almost always an indication of some poor design choices. So whenever you have to pass a this reference to a method, try to figure out why it is necessary. Maybe instead what you actually need is another service, that both classes ("handler" and "connection") can depend on and share.

//register settings inside container
services.AddSingleton<CryptoSettings>(...);
//register crypto service wich has a dependency on settings class
services.AddSingleton<ICryptor, Cryptor>();

class Cryptor : ICryptor
{
     public Cryptor(CryptoSettings settings) {...}
     ...
}

//register settings inside container
services.AddSingleton<CryptoSettings>(here_goes_factory_method_that_loads_settings);
//register crypto service wich has a dependency on settings class
services.AddSingleton<ICryptor, Cryptor>();

class Cryptor : ICryptor
{
     public Cryptor(CryptoSettings settings) {...}
     ...
}