Is it a bad practice to create references between projects in this way?

Question

I have Validator.sln, A.sln, B.sln, C.sln.

A, B, and C are large projects with a different primary functionality. I want to use some of each of their logic to validate a piece of data.

So, in Validator.sln, I have a source file with:

public interface IValidator
{
    bool Validate(int myData);
}

I want to implement this interface in A, B, and C. That is,

public Validator : IValidator
{
    bool Validate(int myData)
    {
        bool dataValidates = true;

        // Call a bunch of complicated logic

        return dataValidates;
    }
}

(This doesn't compile, since IValidator is undefined in this context.)

I could create an assembly reference from A to Validator, which are, for the most part, separate programs. Is that a bad solution?

edit:

I could also put AValidator in Validator.sln, and then dynamically link the assemblies I want from A at run-time. But that sort of defeats the purpose of the interface?

Answer 1

No its not a bad solution.

It is in fact preferable to move common logic into it's own assembly. This saves on code duplication and maintenance costs.

You should also consider moving the logic that is common among the other three projects into the new assembly also.

We have a similar setup to what you are describing. We have a Common assembly that is shared between 3 small applications and this also has business validation (government) rules. Updating a rule across all three applications is incredibly simplified because its only in a single place.