There is a certain model:

public class Post { public int Id { get; set; } [Column(TypeName = "date")] public DateTime? PostedDate { get; set; } [Column(TypeName = "text")] public string Body { get; set; } public int UserId { get; set; } public virtual User User { get; set; } public Post() { Comments = new HashSet<PostComment>(); } } public class ApplicationUser : IdentityUser { public int Id { get; set; } [Column(TypeName = "date")] public DateTime RegistrationDate { get; set; } [Column(TypeName = "date")] public DateTime LastVisit { get; set; } public virtual ICollection<Post> Posts { get; set; } public ApplicationUser() { Users = new HashSet<User>(); } }

and context

 public class ApplicationDbContext : IdentityDbContext<ApplicationUser> { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public virtual DbSet<Post> Posts { get; set; } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } protected override void OnModelCreating(DbModelBuilder modelBuilder) { ... } }

Tell me: - How to wrap all this in the Repository pattern?
- How to spread everything across assemblies ( Entities (Same model), DataAccess (Context, DB settings), Repository (Pattern repository), Services (Services for working with ViewModel) and Web assembly itself (ASP.NET MVC 5))?

  • A repository is an intermediary between data access and business logic, representing an interface as a collection of objects. This pattern is implemented by the ApplicationDbContext class. Its property - DbSet<Post> Posts - this is the "interface in the form of a collection". it is therefore not entirely clear what and what you want to wrap. - PashaPash ♦
  • In my understanding, the Repository pattern is an abstraction that allows you to think of a database as part of an application and implements a mechanism for storing, retrieving, updating, and searching for objects in a data source. Ideally, the program saves and selects domain objects from the Repository as if it were a collection of objects in memory. And ApplicationDbContext in turn (I think) tightly binds us to a specific ORM, i.e. to EF. I also want to try to implement this pattern as a practice. project training. @PashaPash - Aleksandr
  • DbSet <Post> is just IQueryable <Post>. this is an abstraction, untied from a specific ORM and from a specific database. In general, any modern ORM itself is a realization of the Repository + Unit Of Work + Object-relational mapping. Those. in fact, you want to implement a Repository on top of the Repository in order not to depend on what is inside your Repository - it does not make sense. It makes some sense to make a simplified implementation wrapper for the sake of unit tests (by discarding some of the EF functionality). But for the sake of "just training" - definitely not. - PashaPash ♦
  • Clearly, then the question is removed by itself. Tell me how to directly bring the model (DB classes and Identity.EF) into a separate assembly. At the same time, without overriding all Identity interfaces (and is it really real?) @PashaPash - Aleksandr
  • right click on your solution - add new project - class library. Further in the main assembly add links to new libraries (in the solution tab), thus you can use your interfaces. That if I correctly understood the question :-) - bmo

1 answer 1

I have come to such a decision structure. This is a basic structure containing only the most necessary. Then, of course, you need to fill it with your own models.

 Solution |- Domain.Models | |- User | |- Domain.Services | |- IUnitOfWork | |- ApplicationServices | |- IUserService | |- Infrastructure | |- Data | | |- DatabaseContext | | |- UnitOfWork | | | |- DBO | | |- ApplicationUser | | |- UserProfile | | | |- Services | |- UserService | |- ASP.NET MVC Project
  • Domain.Models are the domain models themselves, with business logic
  • IUserService is a user service interface that has methods "Registration", "Login", "Logout" and so forth
  • User and DBO - I keep separate user profile (related information) and Identity model in the database, I make mapping. This is done to ensure that Domain is not dependent on IdentityUser
  • UserService - the implementation of IUserService , actually all the logic of registration, login, etc.

Then use Dependency Injection to embed the IUserService interface into your controllers or other services.

Note

Suppose that IUserService like this:

 public interface IUserService { Task Register(RegisterModel user, bool isPersist = false); Task Login(LoginModel user); Task Logout(); }

There are classes here

  • RegisterModel
  • LoginModel

If everything was in one project, then they would definitely be ViewModels. But since the ApplicationServices level does not depend on the ASP.NET project, the view model cannot be used. I see two options:

  • Declare them in Domain (not too ideologically true)
  • Declare them in the same place as the interface that uses them - in ApplicationServices