As you mentioned in your question, people fork repositories when they want to make a change the code, because you
don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository).
In the forked repository they have write access and can push changes. They may even contribute
back to the original ...
In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub.
When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...
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 ...
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 ...
Git tends to experience performance problems when used with large repositories.
To quote Linus:
And git obviously doesn't have that kind of model at all. Git
fundamnetally never really looks at less than the whole repo. Even if
you limit things a bit (ie check out just a portion, or have the
history go back just a bit), git ends up still always ...
One possible reason: they have running code that depends on those projects and their build process involves pulling the dependencies from github. Having the fork protects them against breaking changes. For projects that don't tag versions, this is the easiest way to achieve that.
The entire point of Github is "social coding".
Personally, I fork repositories when:
I want to make a change.
I think the project is interesting and may want to use it in the future, but have no easier way of saving it for later on the device I'm currently using.
I want to use some or all of the code in that repository as a starting point for my own ...
You've got a lot of moving parts in your question, touching on a lot of concepts, but here's my basic advice when it comes to how to think about a mid-to-large scale MVC application:
Presentation <---> Business Logic <---> Data Access
Firstly, it's best to not think of the the app as "an MVC application". It's an application that uses the MVC pattern ...
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.
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.
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 ...
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). ...
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 ...
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 ...
Repository returns domain objects and is built on top of mapping layers. For a very simple domain domain objects and database tables can be very much the same.
If your repository is always returning exact representation of your data structure then it might actually be Table Data Gateway aka Data Access Object(DAO).
Your database has tables for ...
TL;DR; the equivalent of a git repository is a CVS module, not a CVS repository.
CVS is designed with a notion of modules being a subdivision of a repository, and it is common to use CVS repositories with several modules having a quite independent life. As an example, it is easy to have branches specific to one module and not present in another.
git has ...
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 ...
Short answer ...
Start out with the repositories in your personal account. From there, if/when things grow and/or get popular with the community, move them to an organization account.
GitHub Blog: Repository redirects are here!
Long answer ...
Let's look at some of your options:
For more information on GitHub Organization features, be ...
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.
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 ...
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.
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 ...
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 ...
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"....
If you're adding methods to a repository like
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 ...
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 ...
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/...
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 ...
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 ...
I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:
Make small commits often.
When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit ...