How to implement the repository pattern the right way?

Your questions are absolutely normal, but don't expect to find an absolute answer. Welcome to the software industry!

Here is my opinion:

1. Is it good OOP to have an application that relies on an architecture that, next to their repositories, only has models/classes that hold values with no behaviour?

I think you try to implement a repository pattern, but you miss a higher architecture view. Most apps are at least decoupled in 3 layers: View (Presentation), Business and DataAccess.The repository patterns takes place in the DataAccess, this is where you can find pure data object.But this data access layer is used by a business layer, where you will find a domain model, classes with business behavior AND data.The unit tests effort must be on domain model in the business layer.These tests should not care about how the data are stored.

2. Where do I call repository methods in the architecture of the application?

Again no absolute answer, but usually it makes sense to use Something like a business service. These services could arrange the flow between different domain object, and load, and save them in repositories.This is basically what you do in your AddFriend class, and it belongs into a business layer.

Regarding to unit testing, we need with this approach some dependancy injection, which says to me that it is not a independant class

Business services are ususally dependant on Repositories, it is a really common case for unit testing. The Tram class can hold business behavior and is still independent. The AddTram business service need a repository, and dependency injection allows to test it anyway.

3. Methods that insert, update and delete new entities in a database, are they supposed to be in a class itself?

For this one I can be clear and loud: please don't do that, and yes, CRUD operations belong to the Tram Repository. It's certainly not a business logic. That's why in your example you need two classes in two different layers:

• Tram could be the business object in the business layer (No Crud operation here)
• TramRepository is the object which need to store the data for a Tram (where you will find the CRUD operation)

"Because i have seen some other students making use of static methods in a domain class which provides these functionality"

Use of static methods is clearly not a good idea for that, it means anybody could store data through your object, even though it's supposed to handle business case. And again, data storage is not a business case, it's a technical necessity.

Now to be fair, all these concepts need to be discuss in context to make sense, and need to be adapted on each new project. This is why ou job is both hard and exciting: context is king.

Also I wrote a blog article centered on MVVM, but I think it can help to understand my answer.

The result of this approach was that all my domain classes literally had no behaviour. They were just objects which holds data with no methods.

1. Is it good OOP to have an application that relies on an architecture that, next to their repositories, only has models/classes that hold values with no behaviour?

No of course not, but this is how web developers are being taught these days.

It's back the old modular programming style from the 1970s (static classes + data in objects).
Modular programming caused many problems, so they invented encapsulation and object-oriented languages to solve them.

Making all data public will be fine as long as you are making simple websites:

• load data
• display data
• save data

The problems start if you need complex behavior - then your data is actually part of the software's implementation, and you made it public! This causes serious maintenance problems when there are several developers working on the same project.

Web developers are not being taught OOP. They are being taught a simple way of programming - steering them towards simple websites (which is what governments need).