I would say:
"Validate in every place you can do so."
The sooner you validate, the sooner you provide feedback to the user of the system. This reduces eventual errors, provides hands-on training and eventually improves the user experience.
You need to validate in your business logic, because there are many business rules that won't make it to your UI. The more important reason is that your back end cannot afford to trust your front end, especially over the web.
You need to validate in your repository because the UI isn't the only place that you can make changes to your data.
Especially with this strategy in place, it is very important that data is treated coherently, even if it is not treated consistently. The classic issue of this dilemma is a simple text area input field. It can be no longer than 43 bytes, say, because that is what the database field size is defined to be.
However, the text area in a web browser can accept non-ASCII characters, such as accents and glyphs. So, the string that arrives in your application may fit the text area maximum size, but, when translated to UTF-8 for insertion in your database, it's size might be somewhat larger.
The feedback to the user entering the data has to make sense, even when they don't (rightly so) understand the details of character encodings or database field limits.