Naming conventions and specification infrastructure

[fiseni]

People are already quite familiar with LINQ. Why would we introduce new method names for them to remember? Instead of AddCriteria, let just be Where; instead of AddInclude, let be Include, etc. Other than that, usually it's not quite obvious what functionalities the base classes offer, and users constantly look it up to see what's available. Let simply define property which would encapsulate everything. Simply, it can be this. The statements would look better and more familiar to the users. Might be as following

    public abstract class BaseSpecification<T> : ISpecification<T>
    {
        protected BaseSpecification<T> Query { get; }

        protected BaseSpecification()
        {
            Query = this;
        }
    }

// Usage

    public class MySpec : BaseSpecification<MyEntity>
    {
        public MySpec() : base()
        {
            Query.Where(x => x.ID == 1);
            Query.Include(x => x.MyEntityCollection);
        }
    }

Obviously, we don't need extra property Query, the user simply can use this. It's just a matter of what's more visually appealing.

[fiseni]

I gave a second thought to this. We will utilize a newly created builder which will encapsulate all the methods for creating the specification. So, the Query won't be this, but actually will return a instance of the builder.
I think this will offer much "cleaner" usage, since all the properties that have nothing to do with building the spec are not listed at all.

    public class BlogWithPostsSpec : BaseSpecification<Blog>
    {
        public BlogWithPostsSpec(int id) : base()
        {
            // Query contains only methods for building the spec, which are not available otherwise.
            Query.Where(x => x.Id == id)
                .Include(x => x.Posts)
                .EnableCache(nameof(BlogWithPostsSpec), id)
                .ApplyPaging(10, 20)
                .OrderBy(x => x.Name)
                .ThenByDescending(x => x.Url);
        }
    }

[ardalis]

I agree with using Builder pattern here.

[fiseni]

This issue is addressed with PR #30
If no one has comments, we may close it.