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

New answers tagged

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


0

To help you decide which entities are AR candidates, you should look for invariants, i.e. consistence rules you must guarantee in your model. These rules may define things inside an Entity (like a Person must have a Name) or may define the relation between 2+ Entities. In this case you need to choose one Entity to be the entry point of changes that affect ...


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


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


0

If you have three seperate tables, then creating three Domain Models(Entity Model) and repositories is common way. Then, manage business and transaction scope on Service Layer(Application Layer). If it looks hard to create individual repository for each table, then you can use Generic Repository Pattern. This generic repository lets you use common method ...


Top 50 recent answers are included