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


5

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


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

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


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


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

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


3

The introduction at the top of the criteria for that initiative includes this sentence: For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different organizations. The mention of "...


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


2

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


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


2

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


2

You do not need one repository per table. A repository can encapsulate all data access required for a given entity. The record in the users table is associated with a record in the user types table by way of a foreign key. You can model this in C# as well by replacing the User.FK_UserType property with an actual UserType object. The UserRepositoryDal (which "...


1

You could remove validation from the constructor, make the constructor internal, and call it from the repository to allow unvalidated object creation. If the repository is in a separate assembly, use https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.internalsvisibletoattribute?view=netframework-4.8 Next add a public static factory ...


1

If you don't really have any logic beside fetching data from the repository and showing it, then it is perfectly fine to skip a separate service/application layer. In fact it would be a bad practice to have an extra layer in that case, since you would be complicating the architecture for no benefit. You can always introduce a new layer at a later point if ...


1

This really depends on many factors. For now, I'm going to assume the following layered architecture: Consuming application (e.g. web) > Business > Datalayer > The actual database For one, it depends where your DTO lives. Is this DTO create on the business level, or the datalayer level? If on the business level, then your datalayer doesn't know ...


1

It depends. Only looking for performance, #2 (specific DB update) might look best at a first glance. However, it comes for the price of having to write more SQL code, with a minor violation of the DRY principle. You also have to be more careful if your system supports some local object cache for avoiding duplicate fetches of Person objects. And maybe the ...


1

I agree with other answers that there's nothing specifically wrong with this, it's one valid option. The other main way to deal with this is to use a Map to replace the switch statement. I'm assuming this is Java: Updated The previous version did not guarantee the types were created. Here's one that inherently does. public abstract class AccountType<...


1

As shown in your question, the accounts seem to know their types using some AccountType, so why not just pass that in when you need accounts of a certain type. AccountsRepository { List<Account> getAll(); List<Account> getByType(AccountType type); } If you need to return the accounts typed as the child implementations, I would question ...


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

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

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

Vendoring the other project can be a suitable stopgap measure in the absence of a suitable dependency management tool. In particular, operating in a SCM level can be appropriate if the other project is not a stable, versioned library. Vendoring or mono-repo style projects can be quite beneficial to manage internal dependencies that are developed together, ...


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


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