54

No, think of it this way: a repository is a service (also). If the entities you retrieve through the repository handle most of the business logic there is no need for other services. Just having the repository is enough. Even if you have some services that you must pass through to manipulate your entities. Grab the entity from the repository first and then ...


41

There doesn't seem to be an argument in favor of the big repo in this thread, so here's one: The advantage of a big repo with all your code in it, is that you have a reliable source of truth. All the state in your overarching project is represented in that repo's history. You don't have to worry about questions like "What version of libA do I need to build ...


24

You're dealing with multiple teams and multiple projects. Likely decades of work went into the codebase. The short answer is that your teams and projects have varying needs and varying dependencies. The monolithic repository approach reduces commits to "Everything is stable in this configuration!!!" (i.e. unrealistic, huge commits sourced from many teams). ...


24

They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to]. Sourcetree (a free-as-in-beer GUI Git frontend) allows you to register multiple repositories, organise them into logical groups, and then view status across all of them at once: I am not affiliated with them in any way.


24

You assume the fix does not introduce any new issues and fixes the old ones complete. But lots of fixes are worth a review on their own - and that is probably much easier when the incremental changes can be reviewed separately.


23

No code reuse is usually understood as a selling point for microservices! the microservices can be developed and deployed independently different microservices can use different technologies, in particular different programming languages If this does not seem like an advantage – in particular if all microservices are developed by one team, using one ...


23

Why you shouldn't do it from a team perspective The most important rules of project management regarding teams are: The project can be a success only through intense teamwork. Empowered teams that trust each other are the most effective. One for all and all for one What you are trying to do, is very different. It was called "Divide et impera" by ...


18

And knowing (correct me if I'm wrong) that a repository shouldn't return a DTO Theoretically, every layer (= project in your solution) should have its own DTO objects. In that sense, your repositories should return a DTO, but this is not the same DTO as the "business logic DTO". However, in reality, we don't need that much separation. The benefits do not ...


18

There are projects that have many hundreds of contributors . The Linux Kernel is one that springs to mind, so no having 40 sets of eyes improving code and fixing bugs is not a bad thing. However, what does matter are the change management processes, and the controls in place to ensure that a few bad commits by one developer do not bring the entire ...


17

Well, you can see a good example in the Spring Data Framework which is based on the concept of repositories. There you will see repositories only deal with the data store, and rarely contain any business logic (this is reserved for the service layer). So, for instance, you take a look a their design you will see they have a CRUDRepository interface which ...


14

The idea in Udi's post, as I gather, is that no kind of item appears out of thin air. There is (almost) always something, or more specifically, some domain operation, which caused the item to be created. Just like Udi's example of a user actually being born out of a visitor registering to the site. At that point and at that bounded context Visitor is the ...


14

A facade is more general than a repository. A facade can apply to anything that is not persistence based, whereas a repository is supposed to encapsulate access to an underlying source and make it look like an in memory data source. Facades are for creating a simple interface for some other, complicated interface.


13

Whenever you have a class with more than 1 method, you can question if the SRP is fulfilled, since each of the methods will (typically) solve a different task or problem and so has a "different responsibility". But that's actually not the way I understand the SRP - SRP means IMHO "single responsibility at the correct level of abstraction"....


13

What is the purpose of domain/business logic in classes when having repositories? This is kind of like asking: What is the purpose of cars when we have garages? The reason is that Business Classes and Repositories solve different problems, and therefore are different Concerns in the application. As such, they need to be in separate classes. A ...


12

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


12

What a repository does is translate from your domain onto your DAL framework, such as NHibernate or Doctrine, or your SQL-executing classes. This means that your repository will call methods on said framework to perform its duties: your repository constructs the queries needed to fetch the data. If you're not using an ORM-framework (I hope your are...), the ...


12

If you're adding methods to a repository like GetById GetByName GetWithIncludesABC GetWithIncludes123 Then you're better off moving to a Service Layer, and letting the Service Layer use EF directly. EF already has functionality similar to the above methods that you're just endlessly duplicating. A Service Layer exposes Business Domain methods, and ...


11

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database. To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/...


10

It is not bad practice for a controller to call a repository directly. A "service" is just another tool, so use it where it makes sense. NikolaiDante commented: ... Pick the right pattern for the right application. What I would say is that you should make your application consistent. I don't think consistency is the most important aspect. A "service" ...


10

Your question talks about repositories being IQueryable (i.e. classes implementing the IQueryable interface), whereas your linked resource talks about repositories returning IQueryable objects. That's not the same thing. For the purpose of this answer, I'm going to assume you misspoke and meant to focus on repositories returning IQueryable objects. What is ...


10

You are not Apple or Microsoft. The reason why a software developer at Apple doesn't know about all of Apple's code is that there is a bloody awful huge amount of code and nobody can know about all of it. And there isn't one guy at Apple in charge of their repository. They have more than one :-) What you are thinking about is just totally misguided. If ...


9

I think you should think who has an interest to change that respective class. For example if you have an User class with an CalculatePay method and a save method. The accountant would want to change the CalculatePay and the DB administrator the save method. These are two different responsibilities. The SRP means grouping together things that change for the ...


9

Don't test trivial or obvious repository methods. If the methods are trivial CRUD operations, all you're really testing is whether parameters are mapped correctly. If you have integration tests, such errors will become immediately apparent anyway. This is the same principle that applies to trivial properties, like this one: public property SomeProperty { ...


9

The purpose of a Repository is to provide an abstraction layer for data access. That abstraction layer should shield the user of the repository from the details of accessing the data. Things like connection strings, data sources, switching to a different data source... Your user shouldn't have to worry about those things. In other words, the user of a ...


9

When you use void updateTitle(String str) { this.title = str this.store.update(this); this.notifier.notifyAboutChange(this); } you are grouping two operations into one -- updating the model in memory and making the updated model persistent. This is a policy decision you have to make for your application. Only you and your team are in a position ...


9

No, domain objects should not have any idea of the existence of a repository, or even a repository interface. If you feel the need to do this, that means there is an underlying issue with your design (see below). The root of your problem is that you have not modeled all of your entities properly. A course does not have students it has registrations. Not ...


9

It would be wasteful to always fetch the entire objects. First I would question this. If your objects are well-designed and not too bloated, the performance and memory overhead of fetching them completely instead of getting them partially is often negligible for most real-world cases. The performance of SQL queries over a network are way more dependend on ...


8

While in general injecting something is not bad and does not automatically result into breaking the SRP (nor it does in your case - you have one class which only fetches data and another constructing an object from it), you have a different problem: wrong understanding of layering and abstraction. The repository layer is the one to bind data to your domain ...


8

If your repository layer is properly abstracted (eg, the service layer and controller can only access the repository via interfaces), then: Having the controller access the repository directly simplifies that part of the code as it removes an unnecessary level of abstraction, but You are then coupling the controllers to both the service and repository ...


8

My understanding is: DAL (Data Access Layer) refers to a layer in your software that sits between your persistence technology and your application logic. Its purpose is to keep data access concerns separate from the rest of your application concerns. It is a general concept. Repository is a concept from DDD (Domain Driven Design). In DDD, a Repository ...


Only top voted, non community-wiki answers of a minimum length are eligible