I find this much more readable:
// some other layer
var users = from user in allusers
users = MatchIsActive(users, searchVO);
users = MatchFirstname(users, searchVO);
users = MatchLastname(users, searchVO);
users = MatchId(users, searchVO);
users = MatchSomeFutureValue(...
Best way would be to have a type system that doesn't have "implicit null" for reference types. That means, that all references are non-nullable by default and can only contain null when explicitly defined.
This is possible in C# 8 with never version of a compiler using Nullable reference types. This way, the client knows if returned reference value can or ...
The point of microservices is to enable independent development and operation of parts of a larger software system. What is your goal in this project, what is the reason you are doing this?
A microservice is not a subtree of a data model. It is a closed, feature complete part of the whole, that has (ideally) no request-response dependency to other systems, ...
Assumed you don't want to change the existing User object significantly, you could use reflection to
iterate over the properties of UserSearchVO
check for the equally named properties of User
implement a generic comparison of those properties for the data types required
This approach can be extended by providing custom attributes to the properties of ...
A null object, in the context of the Null Object Pattern, is simply an object that does nothing when some operation is invoked.1 The idea is to avoid dealing with special cases - this includes, but is not limited to, avoiding null checks; e.g., you may want to do nothing if a certain set of conditions is not met. The calling code (client code) is written ...
Just try it and see if your callback is called once or twice when you call it twice. I mean if someone says “yes, it’s ok”, would you just believe it without verifying? And when you verify it, there’s no need to ask the question anymore.
But if you call it twice, what’s absolutely needed is a comment that calling it twice is Ok and why.
UserSearchVO is just a search expression
Your UserSearchVO object represents a search expression. So it seems reasonable that the UserSearchVO class would know how to convert itself into an Expression<Func<User,bool>>, which you could then provide to the Where clause. A simple example might look like this (thanks to this answer):
I would go for a builder pattern:
var users = SearchUserWhich
Now you can combine the filters internally the way you want until you call .Fetch.
Basically you are wrapping SQL in a (limited) DSL because you're not using a nice SQL DSL for whatever reason (e.g. you do need that ...
Pardon me if I've misunderstood your question, but the way I see it Newtonsoft.Json library has JObject class which actually represents dynamic JSON piece. Here's the snippet code which shows how you can query it to get only the properties you're interested in your business logic.
Object oriented design
The alternative without Hand class is continue to use a List and write all the logic about compare hand in a module Hand Evaluation.
What you suggest is not impossible, but it's orthogonal to an object oriented approach. In OOP, you define concepts (objects) which represent a state. A hand, a given selection of cards, is a prime ...