CODEWITHSUNDEEP
architecturerepositoryclient-server
Ari
Ari

Reputation: 6189

Repository architecture vs Client-Server architecture?

Prepping for an exam and it asks:

What are the key aspects of a repository architecture that differentiate it from a client-server architecture?

My response to that is:

Repository architecture is centralised data that can be accessed by multiple components to store and edit data, a change on one component is replicated across all components, data is processed on the client side. Client-Server can have multiple servers and clients each interacting with each other to offer services, data and services are processed on the server side.

Is that correct, and would you think that answers the question? I also feel like Client-Server and Repository are not so easily comparable, as you could have a repository system operating within a Client-Server architecture.

Upvotes: 0

Views: 2813

Answers (1)

Zazaeil
Zazaeil

Reputation: 4119

I would not agree. Repository is definitely a way to implement Client-Server pattern, in particular - server side. Having a server implies existence of a client, at least one. Even if there is no centralized database somewhere, there still exists data layer that might be local to a client. Without somewhat kind of data layer you're limited to "in-memory" applications only: they have no state at all (including absence of user settings, for example). I assume that your question is not limited to those.

The idea stays behind repository pattern is a necessity to abstract out data IO implementation details. It hides certain structure of database, it's configuration, mapping and (rarely) validation logic inside of an appropriate IRepository class. Normally these guys are generic, so programmers deal with IRepository<T> with some additional constraints put on the T. Hence, having such an interface in place allows you to: 1) use conceptually different databases simultaneously, keeping other code unware of their principal differences (imagine traditional SQL along with graph-based database), 2) replacing different databases with no change made to outter world: say, you decided to get rid of MSSQL and move to a Neo4j or vice versa, 3) finally, the last but definitely not the least, you get a razor-sharp edge of a certain "responsibility" - data IO. That acts as a convinient extension point to inject extensions like validation or logging.

Upvotes: 1

Related Questions