I'm currently in a university course that requires students to work in groups on a semester-long project. In my group's case, we've been tasked with making a location-tracking system. There are two primary components to the system: the backend (which houses the datastore, exposes endpoints, et cetera), and the mobile app our users interact with. Users who've enabled tracking via the client app will have their location pinged to the server at a regular interval. Each user is also able to view the position of tracked users near their current location.

To me, this scenario seems to lend itself to the client-server architecture. One of my groupmates, however, felt that it "is most similar to the repository style architecture." Am I missing something? On a somewhat related note, does the repository architecture differ from what's discussed in this video: https://www.youtube.com/watch?v=rtXpYpZdOzM? If not, can't the repository pattern and client-server architecture exist in tandem?

Here are a couple of slides from the course, for reference:



2 Answers 2


Indeed your instinct is correct. These two concepts, Repositories and Client-Server, are two wildly different concepts and abstractions. They are completely orthogonal to each other. They can both exist within the same application. Indeed a client-server system might even have two Repositories, one in the client and one in the server.

Repository feels more like an OOP design pattern to me now, and not a system architecture like client-server.

  • 1
    This isn't entirely correct. There is a design pattern called Repository (msdn.microsoft.com/en-us/library/ff649690.aspx) , which, like you stated feels very natural in ORM, and it defines ownership over data access, but, there is also a Repository Architecture (tutorialspoint.com/software_architecture_design/…), which means there is a central data store, where application use it directly, without a middle layer, like in client server (the server is the middleman). But, like with any other pattern, implementations can vary. Commented Feb 8, 2018 at 20:51

Most real world systems employ multiple architectural patterns. In your case the interaction between the mobile and the backend is clearly client/server, but the backend will have a data store behind it which more closely fits the repository pattern.

My advice would be don’t get too hung up on which pattern you are using because you might end up forcing everything into that pattern even when it doesn’t make sense. Instead focus on what’s needed to make the system work efficiently etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.