What is the Correct Way to Call a Method That Has Been Overridden as Protected in Another Class from Another Class?

Question

What is the Correct Way to Call a Method That Has Been Overridden as Protected in Another Class from Another Class?

fatih uyanık 225

Hello

I have Repository and service classes in my c# wpf project. For example, BookService, AuthorService, which inherit from BaseService. When adding DI, I add them via the interface and when using them, I inject and use them via the interface. BaseService includes basic CRUID and basic validation operations. As the project progressed, a need arose. For example, when saving a book, I added special validations by overriding the validate method in BaseService with BookService and finally I ensure that basic validations are applied by calling base.Validate(). This does not cause a problem for the Book object when the BookService works directly. However, when I try to call the Validate method, which is overridden in AuthorService while recording via BookService, I cannot access the AuthorService.Validate method via BookService because it is overridden in a protected manner. In order to prevent this and preserve the current structure, I defined an auxiliary public method and added it to the IAuthorService interface and developed a method to call validation for that service from another class.

Will such a usage cause me problems as the project grows? Can you suggest a different approach to achieve my goal?

The question is a bit long. Sorry,

Thank you.

3 answers

Your answer

Answer 1

Martin Brandl 545 MVP

In general - I would prefer composition over inheritance and use inheritance only in rare cases because it creates tight coupling, making changes harder to manage and reducing flexibility.

While your approach works, it introduces tight coupling since validation is bound to the service hierarchy, violating Separation of Concerns. I recommend moving validation to separate validator classes, making the system more modular, reusable, and testable

Answer 2

Jack J Jun 25,296

@fatih uyanık, Welcome to Microsoft Q&A, based on your description, your current approach works in the short term but may cause maintenance issues as the project grows.

Here are the main concerns:

Tight Coupling – BookService depends on IAuthorService validation, creating unnecessary dependencies.
Unclear Responsibilities – BookService handles both business logic and validation, which breaks the Single Responsibility Principle.
Poor Scalability – If more services require cross-validation, adding more public validation methods will make the code harder to manage.

I recommend that you create Separate Validator Classes to deal with Validate.

Here is a code example you could refer to.

public interface IBookValidator { void Validate(Book book); }
public class BookValidator : IBookValidator
{
    private readonly IAuthorValidator _authorValidator;
    
    public BookValidator(IAuthorValidator authorValidator)
    {
        _authorValidator = authorValidator;
    }
    public void Validate(Book book)
    {
        if (string.IsNullOrEmpty(book.Title))
            throw new ValidationException("Title is required.");
        
        _authorValidator.Validate(book.Author);
    }
}
public class BookService : IBookService
{
    private readonly IBookValidator _bookValidator;
    
    public BookService(IBookValidator bookValidator)
    {
        _bookValidator = bookValidator;
    }
    public void Save(Book book)
    {
        _bookValidator.Validate(book);
        // Proceed with saving
    }
}

By using the above method, you can know the following advantages:

Services stay focused on business logic.
Validators can be reused in multiple places.
Easier testing and maintenance.

Hope it could help you.

Best Regards,

Jack

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

fatih uyanık 225 Reputation points

2025-02-14T10:08:40.6466667+00:00

Hello @Jack J Jun From what I understand, I would redefine the validations for each service as a separate validator and call them again wherever I want. Then do I need to create an interface for them? After all, I will have to register them in the DI container.

Thanks.
Jack J Jun 25,296 Reputation points

2025-02-14T11:01:42.4466667+00:00

@fatih uyanık, thanks for the response, yes, if you're using dependency injection (DI), it's a good practice to create interfaces for your validators.

It has the following advantages:

Lower coupling - Services rely on abstractions (like IBookValidator) rather than concrete implementations (like BookValidator).

Easy Dependency Injection - Interfaces allow the DI container to manage and replace different implementations.
fatih uyanık 225 Reputation points

2025-02-14T11:52:56.11+00:00

Hello

I want to ask one last thing. Actually, there are validators in my project. (BookValidator, AuthorValidator) In my project, these perform validations of models with FluentValidation.

Apart from this, there are also validations performed by querying the database. For example, is there a book?

Now, I think it would not be right to put validations related to the database in validator classes. How and where should I perform these?

Thank you.
Jack J Jun 25,296 Reputation points

2025-02-14T12:24:18.6266667+00:00

@fatih uyanık, ok, as usual, the best approach is to separate model validation and database validation, I suggest that you could perform database validation at the service layer.

Please look at the following suggestions:

a. I recommend that you use FluentValidation for simple checks (e.g., required fields, length, format).

b. please perform database-related validations in the Service Layer before executing business logic.

c. please avoid database queries inside FluentValidation, as it mixes concerns and affects performance.
fatih uyanık 225 Reputation points

2025-02-14T18:40:42.11+00:00

Hello

So should I write validations in services? Or should I create separate validator classes for them? Should I continue with the approach I have applied?

I would be glad if you could show a small application.

.Thanks.

Jack J Jun 25,296

@fatih uyanık, we need to write FluentValidation for basic model validation.

For example:

public class BookValidator : AbstractValidator<Book>
{
    public BookValidator()
    {
        RuleFor(book => book.Title)
            .NotEmpty().WithMessage("Title is required.");
    }
}

We need to write database validation in service Layer.

For example:

public class BookService : IBookService
{
    private readonly IBookRepository _bookRepository;
    private readonly IBookValidator _bookValidator;
    public BookService(IBookRepository bookRepository, IBookValidator bookValidator)
    {
        _bookRepository = bookRepository;
        _bookValidator = bookValidator;
    }
    public void Save(Book book)
    {
        _bookValidator.ValidateAndThrow(book);
        if (_bookRepository.Exists(book.Title))
            throw new ValidationException("Book already exists.");
        _bookRepository.Add(book);
    }
}

Please free to let me if you have any questions.

fatih uyanık 225 Reputation points

2025-02-17T06:27:53.5266667+00:00

Hello

So wouldn't doing database validations inside services be considered against solid principles?

Well, after your messages, I did some more in-depth research. Would it be a good practice to move service validations to separate validator classes and do all the validations there and call them from the service? Or would it be unnecessary?

Thanks.

Jack J Jun 25,296

Hi @fatih uyanık,

So wouldn't doing database validations inside services be considered against solid principles?

No, database validation is part of the business logic and is placed in the Service Layer in accordance with the SOLID principles.

Would it be a good practice to move service validations to separate validator classes and do all the validations there and call them from the service? Or would it be unnecessary?

It depends on complexity. Here are two approaches:

First, you could Keep Model & Database Validations Separate.

Model validation → FluentValidation (BookValidator)

Database validation → Service Layer (BookService)

public class BookService : IBookService
{
    private readonly IBookRepository _bookRepository;
    private readonly IValidator<Book> _bookValidator;
    public BookService(IBookRepository bookRepository, IValidator<Book> bookValidator)
    {
        _bookRepository = bookRepository;
        _bookValidator = bookValidator;
    }
    public void Save(Book book)
    {
        //  Model validation
        _bookValidator.ValidateAndThrow(book);
        //  Database validation
        if (_bookRepository.Exists(book.Title))
            throw new ValidationException("Book already exists.");
        //  Proceed with saving
        _bookRepository.Add(book);
    }
}

Second, If database validation logic becomes too complex, you can create a separate validation class:

public class BookBusinessValidator
{
    private readonly IBookRepository _bookRepository;
    public BookBusinessValidator(IBookRepository bookRepository)
    {
        _bookRepository = bookRepository;
    }
    public void ValidateBookRules(Book book)
    {
        if (_bookRepository.Exists(book.Title))
            throw new ValidationException("Book already exists.");
    }
}
public class BookService : IBookService
{
    private readonly IBookRepository _bookRepository;
    private readonly IValidator<Book> _bookValidator;
    private readonly BookBusinessValidator _bookBusinessValidator;
    public BookService(IBookRepository bookRepository, IValidator<Book> bookValidator, BookBusinessValidator bookBusinessValidator)
    {
        _bookRepository = bookRepository;
        _bookValidator = bookValidator;
        _bookBusinessValidator = bookBusinessValidator;
    }
    public void Save(Book book)
    {
        _bookValidator.ValidateAndThrow(book);
        _bookBusinessValidator.ValidateBookRules(book);
        _bookRepository.Add(book);
    }
}

You could use first suggestion (Service Layer Validations) unless the validation logic is complex. 🚀

You could use second suggestion (Separate Validator Class) only if multiple services need the same database validation logic.

Jack J Jun 25,296 Reputation points

2025-02-24T08:17:26.54+00:00

Hi, @fatih uyanık, I have not heard from you for a couple of days. Please let me know if there is anything that I can help here.

Answer 3

Bruce (SqlWork.com) 77,686 Volunteer Moderator

Issues like this is why inheritance is often considered an anti-pattern. in you case each inheritance may have different validation rules, so it better to unique named methods, interfaces or extension methods.

note: if you need to cast, then unique names is probably better

((Book) referenceBook).Validate();         // cast required due to inheritance 
validation.Validate((Book) referenceBook); // cast required due to inheritance 
validation.ValidateBook(referenceBook);    // explicit

Share via

What is the Correct Way to Call a Method That Has Been Overridden as Protected in Another Class from Another Class?

3 answers

Your answer