Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
6

As I see it, the key problem you are trying to solve is an avoidance of duplication of effort. I.e., once a problem has been solved you would like to not solve it again. In my opinion, no existing approach both solves that problem perfectly and doesn't require a fair amount of time to set up correctly. That said, there are plenty of partial solutions with ...


5

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 ...


5

The immediate problem I see here that it becomes hard to unit test the "UnitOfWork" with mock repositories. What if the line repoItem = new Repository<TEntity, object>(Context); needs to be replaced by ... new MockRepository for a meaningful test? So in case UnitOfWork just needs one or two, maybe 3 repos, you could try to inject them in the ...


5

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 ...


4

Yes. You need a unique Id for these things and the DB id fits the role. Ideally the unique id is independent of the database though. Have a GUID on your business object and use that as the DB key rather than the other way around. But 99.9% of the time its going to be a purely conceptual difference.


4

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. ...


4

A. Where can I place the validation? Regardless of your design there are two places where validation code goes: Near input Near use You put validation near input so that you can show the user the mistake quickly and get a correction timely. Also so that you understand the users context well. You put validation near use to protect against the many wild ...


4

In my experience, at least in in application development, it is seldom necessary to decide this beforehand. Instead, I would recommend to start with one repo class and see how far it brings you. When the code base grows and you get some indications that splitting up the repo into two becomes beneficial, then refactor immediately. Such indications are the ...


4

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 ...


3

There is definitely an interesting problem at play here; but I think you're looking at it the wrong way. Your question is, at some points, dangerously close to becoming an XY problem, as you seem to be indirectly asserting that caching (Y) is the solution to loading referenced data (X). Some short feedback on why I'm not a fan of your suggested solutions, ...


3

The way you reduce network latency is by "chunking" your queries; that is, by retrieving a larger chunk of data on each request. One way you can do that is by dealing with business domain aggregates instead of individual database records. Instead of using generic method names like FindByIdWithChildBAndGrandChildC (which is just a more sophisticated form of ...


3

If the server isn't located on the same physical machine as the application making the call, your design should try to minimize the total number of queries, especially small queries, because network latency can take up a disproportionate amount of time. True story: I once turned a report-generating task that was taking over 24 hours to run into one that ...


3

OP here. For posterity, I wanted to add what my ultimate solution to this problem was. I will keep the best answer checked, because it's actually the best answer when things go smoothly. First, I tried the selected answer from Doc Brown: https://softwareengineering.stackexchange.com/a/370419/291998 But the svnadmin dump command failed about halfway ...


3

It's better to be consistent and always call the service layer even as a pass through. Consistency is more important than saving a few lines of uninteresting code. This allows you to add potential business logic to accommodate future changes, and can help act as a signal that you aren't separating your business logic as much as you should if you have a lot ...


3

There is absolutely nothing in that interface that leaks the details of the implementation. Without issues you can implement a concrete class with EF, or Dapper, or even MongoDB or whatever you want. You would have an argument if that interface had some sort of SaveChanges() method or some other pattern or requirement that was essentially driven by EF and ...


2

The dependencies required for the repository classes shouldn't be needed by the controller classes. If you don't mind having the dependencies there, I suppose you could skip the pass-through call and go straight to the repo. It boils down to do you care that the controller now has a dependency on the repositories. I've made the assumption that your ...


2

I think the core of your question is language agnostic. I have little PHP-specific experience here, but the separation of entities and the ORM is something I did tackle this week in our project. You're correct in identifying that separating the entity from the ORM is a good decision. Your entities define your data structure, whereas your ORM defines where ...


2

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 ...


2

It's a general aspect of inheritance that you can't remove stuff. In your specific example you could just ignore the protected repository, but it would potentially break further inheritance, or at least confuse it. A simple solution would be just not to inherit from GenericModel at all, but I suppose we can assume GenericModel has some other public ...


2

No, it's not bad to have private classes in repositories. I guess the confusion would be around why you need a private class. Rather than another option. Use an existing public class. Your Repository is a conceptual storage for public classes, If I need to ask a question about the state of that data, can I not use the public class it maps to? Don't map to ...


1

As I get your code, you have three options: 1. Use your Factory Pattern Method implementation class AccountRepositoryImpl (It would be better if you use switch-case instead of if/else statements.) : By factory method, caller class won't know anything about your AccountType. Which clearly violates some design principles (every time a new Account is ...


1

Your else/if statement is essentially an implementation of the Factory Method Pattern. So if your code violates some design principles, then so does this well-known pattern.


1

I think the question here is; do you need a whole city object for the User? Fair a user is a resident in a city, but in this particular domain, are you concerned with the city details (name, country, etc) from the perspective of the user? or will just having the cityId suffice? - that is to say, would your require functionality to change the name, country, ...


1

I think the issue you are describing (and therefore the use-case you necessitate) is being caused by boundaries being drawn in the wrong places. A City is clearly an Entity in it's own right subject to it's own vectors of change. For example, clearly you wouldn't change the name, population, etc. of a City through a User. The relationship between a City and ...


1

The way I've handled it in the past is to have each api in the chain have two client libraries. One is the normal, 'connect to the api server' client lib. The second reads its responses from files rather than connecting to a server. Both these libraries live in with the Solution which contains the api itself. Integration tests, for that service, use the ...


1

Whether something should be in your shared library/boiler plate or not depends on the potential clients that could make good use of it. So the answer to the question "should this be in my shared bits" may very well change over time. The decision is yours. Would it make your life easier?


1

Using surrogate keys outside of a database is fine if those keys are 100% immutable and are guaranteed to never change afterwards (since you typically cannot update them in external systems) even though those keys get more visibility this way, you can restrain any stakeholders from inventing new "business requirements" for these keys (like "lets use a magic ...


1

You are comparing two different and complementary concepts: The Data Access Layer is an architectural layer that intends to abstract access to data. It doesn't say how the access shall be abstracted. The Repository is a specific pattern that belongs to the DAL (see list of patterns at the end of this link). It says exactly how to abstract a specific ...


1

I suggest you look at the build system for existing libraries like Boost or my own Stroika. These are two open source libraries with relatively simple branch structures (in git). They are both cross platform. In both cases, there is no connection between branching and platforms. Generally - you will want to use a directory hierarchy with your source code ...


1

The repository should return a Domain Model. You should have a single repository per database, rather than one per table. In your case if you want both domain models in as single query then you could either Change your Domain Model so that A has a child object B Have two separate methods still, but cache the results, so that the second method called, ...


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