Last post Jun 20, 2019 08:50 AM by Sherry Chen
Jun 19, 2019 05:27 PM|Test1233@|LINK
Hi, I am building my project in such a way that I have a single SPA angular asp.net core application which call separate Web API asp.net core projects based on the angular modules they are configured. Now, I want to know the best possible approach I could
take to make managing my databases more easily. Should I create a class library separately that will solely handle all the db calls or should I put each db calls inside of the Web api projects. Also I am planning to user Repository pattern but am not sure
if it is required in EF Core. Also, I don't want to use SQL Server. So, what are the best practices to follow?
Jun 19, 2019 05:57 PM|mgebhard|LINK
Now, I want to know the best possible approach I could take to make managing my databases more easily. Should I create a class library separately that will solely handle all the db calls or should I put each db calls inside of the Web api projects.
My best guess is you are asking whether to create a service or make DB calls from an action method. I recommend building standard Core services and inject those services into class constructors. These are classes like controllers, business logic (domain
logic), and other services.
Also I am planning to user Repository pattern but am not sure if it is required in EF Core.
Only use a design pattern if it solves a programming problem. In my experience, the repository pattern is common but not significant by any means. The repository pattern is not dependent on an ORM like EF Core or data access API.
So, what are the best practices to follow?
Given this post and your similar posts, I recommend building demos or proof of concepts to get a feel for the fundamentals.
Jun 19, 2019 06:12 PM|DA924|LINK
EF Core works with a verity of database providers. If I am going to use a database, then it will be one that is well documented on how to use.
I am not a big fan of the generic Repository as it's too limited in scope. And besides, the Repository pattern object is not a persistence object.
I think SoC is appropriate in the WebAPI, like using a DAL, Data Access Layer classlib project and the Data Access Object pattern in low level mapping using EF or a Repositroy classlib project with both using an Interface.
You should also consider using the DTO pattern with the DTO(s) in a classlib project that is known by the WebAPI client and the WebAPI service.
Jun 19, 2019 06:23 PM|bruce (sqlwork.com)|LINK
what does the webapi do beyond making the database calls? You should design the webapi interface before you worry about the EF design. will it be transaction based? query based? For SPA's graphQL is a popular design pattern. if you are using page modules,
it might make sense for a webapi controller for each module, but this depends on the design.
note: EF is already a repository pattern, so there is not much point of using another Repository layer, unless you want to use other entity frameworks.
Jun 20, 2019 08:50 AM|Sherry Chen|LINK
Hi Test1233@ ,
Repository and unit of work patterns are intended to
create an abstraction layer between the data access layer and the business logic layer of an application. Implementing these patterns can help insulate your application from changes in the data store and can facilitate automated unit testing or test-driven
development (TDD). However, writing additional code to implement these patterns isn't always the best choice for applications that use EF, for several reasons:
You could take aside time to read the below articles written by Jon P Smith :
Is the repository pattern useful with Entity Framework Core?
Six ways to build better Entity Framework (Core and EF6) applications
Best Regards ,