You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current source file redis-sharp.cs defines two classes in the global namespace: Redis and SortOptions. The combination of basic client communication and protocal handling with specific client commands in one class Redis makes it hard to add different kinds of clients. A separate client connection only using specific commands is needed for Redis pub/sub messaging. See also pull requests #4, #8, #9. Alternative existing C# clients provide a deeper integration with C# features. They all start from scratch regarding the general client interface though.
Currently the class Redis defines:
class Redis
enum KeyType
class ResponseException
Redis (host, port), Redis (host), Redis
Db
Set, SetNX
MSet (implements encoding of key/value tuples, call SendDataRESP)
Get
Sort
GetSet
ReadLine
Connect
SendDataCommand (call SendDataRESP)
SendDataRESP (implement send to socket)
SendCommand (re-implement send to socket)
Log
ExpectSuccess
SendExpectSuccess
SendDataExpectInt
SendExpectInt
SendExpectString
SendGetString
SendExpectData
ReadData
ContainsKey
Remove
Increment
Decrement
TypeOf
RandomKey
Rename
Expire
ExpireAt
TimeToLive
DbSize
Save
BackgroundSave
Shutdown
FlushAll
FlushDb
LastSave
GetInfo
Keys
GetKeys
MGet
SendExpectStringArray
SendExpectDataArray
#region List commands
#region Set commands
Dispose (call QUIT and close socket)
class SortOptions
RedisSharp is out-standing for it's simplicity, which should be kept. Advanced C# features, like an asynchronous client or deeper integration with C# data structures, can go on top of a common basic C# client interface.
This is why the class Redis should be split into two classes: one for basic client communication and a second for specific commands. Moreover, if more classes get defined, including also classes with generic names like SortOptions, then they should be grouped in a namespace.
The grouping could be (bold face marks new things):
namespace RedisSharp class RedisClient -- cf. redis-cli just providing communication and encoding
SendDataRESP --> SendRaw(implement send to socket once)
SendTuplesCommand(separate encoding of key/value tuples from MSet and call SendRaw)
SendDataCommand (assemble byte array and call SendRaw)
SendCommand (assemble byte array and call SendRaw)
ReadLine
ExpectSuccess
SendExpectSuccess
SendDataExpectInt
SendExpectInt
SendExpectString
SendGetString
SendExpectData
ReadData
SendExpectStringArray
SendExpectDataArray
Dispose (close socket)
class Redis : RedisClient
enum KeyType
Redis (host, port), Redis (host), Redis
Db
Set, SetNX
MSet (call SendTuplesCommand)
Get
Sort
GetSet
ContainsKey
Remove
Increment
Decrement
TypeOf
RandomKey
Rename
Expire
ExpireAt
TimeToLive
DbSize
Save
BackgroundSave
Shutdown
FlushAll
FlushDb
LastSave
GetInfo
Keys
GetKeys
MGet
#region List commands
#region Set commands
Dispose (call QUIT)
SortOptions
The separation of redis-sharp.cs into two files RedisClient.cs and Redis.cs makes it hard to track changes, because methods move (like the Set commands from on top of RedisClient.Connect into Redis extending from RedisClient. Moreover the indentation changes with a namespace. This is why the opportunity could be used to introduce more moves and group the Redis commands according to the Redis documentation into regions Keys, Strings, Connection, Server (see http://www.redis.io/commands). One might also introduce separate regions for 1:1 implementations of Redis commands -- like Set (key, value) -- and C# extendsions -- like Set (dictionary).
Alternative client implementations can then extend from RedisClient as well, e.g.:
The current source file redis-sharp.cs defines two classes in the global namespace:
Redis
andSortOptions
. The combination of basic client communication and protocal handling with specific client commands in one classRedis
makes it hard to add different kinds of clients. A separate client connection only using specific commands is needed for Redis pub/sub messaging. See also pull requests #4, #8, #9. Alternative existing C# clients provide a deeper integration with C# features. They all start from scratch regarding the general client interface though.Currently the class Redis defines:
class Redis
class SortOptions
RedisSharp is out-standing for it's simplicity, which should be kept. Advanced C# features, like an asynchronous client or deeper integration with C# data structures, can go on top of a common basic C# client interface.
This is why the class Redis should be split into two classes: one for basic client communication and a second for specific commands. Moreover, if more classes get defined, including also classes with generic names like
SortOptions
, then they should be grouped in a namespace.The grouping could be (bold face marks new things):
namespace RedisSharp
class RedisClient
-- cf. redis-cli just providing communication and encodingclass Redis : RedisClient
SortOptions
The separation of redis-sharp.cs into two files RedisClient.cs and Redis.cs makes it hard to track changes, because methods move (like the Set commands from on top of RedisClient.Connect into Redis extending from RedisClient. Moreover the indentation changes with a namespace. This is why the opportunity could be used to introduce more moves and group the Redis commands according to the Redis documentation into regions Keys, Strings, Connection, Server (see http://www.redis.io/commands). One might also introduce separate regions for 1:1 implementations of Redis commands -- like Set (key, value) -- and C# extendsions -- like Set (dictionary).
Alternative client implementations can then extend from RedisClient as well, e.g.:
namespace RedisSharp
RedisSub : RedisClient
RedisSubEventArgs
The text was updated successfully, but these errors were encountered: