An ASP.Net Core RESTful API can be implemented in different ways. This article will dissect the various steps involved in implementing one using th...
For further actions, you may consider blocking this person and/or reporting abuse
Very good article. Exposing code patterns which are better served by going generic is a mark of maturity.
Mark of maturity...lolz!
Thanks for the review dear John
Nice one. A simplified approach.
Yea. Thanks for your review Chief
Thanks alot dear Sir
Well presented. Really demystified it. Thanks for the article.
Thanks for your feedback dear friend.
Nicely put. But where do my business logic and calculations belong? I don't think the logics and calculation should be done either in repository or controller.
Yea, you're right. Business logic should not be placed directly into Models, Views, or even Controllers because it will reduce the re-use and maintainability of your code. The scope of this article is trivial but for none trivial applications, I'll suggest you create a business logic layer and simply call the business logic layer from your models when needed. The business logic layer will in turn call into the data access layer.
I'll note that if you want the RepositoryBase methods (Create, FindAll, etc.) to be callable when using RepositoryManager, then the IRepositoryManager members Department and Student should be the class references DepartmentRepository/StudentRepository, rather than the interface references IDepartmentRepository/IStudentRepository.
What would be the best way to force others to use the repository classes and restrict them from going directly to the EF objects and DBContext?
Clean. Logical. Brilliant. Pick any 3. Thanks!