Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am in confusion about the data access technology in mvc4 whether we should use Entity Framework or Linq or something else which is better than this ?
I have research much in this topic and not satisfied with all.?So can you help me about this with proper Detail?
The question will have answers upon user based opinions and experience.
This is what my personal recommendation is Model:
Take this as a Tree View Structure
1. Controller
2. ActionMethod //call the desired Factories
3.1 View Factory //to get data in DB
3.2 Domain Factory //to set data in DB
4. Services //Interface for Caching and top operations
5. Repositories //Contains on CRUD Operations
Inside the Repositories I would prefer LINQ-to-Entities rather than LINQ-to-SQL.
A great way of UNIT OF WORK PATTERN is being explained here
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Simple 'best practices' question, hopefully not too opinion based:
In my Core 2.2 MVC app, I want to use a custom ApplicationUser class to implement IdentityUser class.
Where should I save this class in my file structure?
I'm thinking a Users/ApplicationUser.cs maybe?
The MS Docs show how to implement, but don't recommend where to put the actual class. I know it's probably arbitrary, but I am not a professional programmer, so the only way for me to know these 'common knowledge' things is to ask all you real developers lol.
Thank you!
Just to close out the question:
EdSf's answer is what I went with. After more research the other day I found multiple tutorials on the subject and they put their custom ApplicationUser classes in the Models folder as well.
I know it's arbitrary and opinion based, but for what it's worth, people seem to agree that the Models folder is a good place for the custom ApplicationUser class.
Thank you for the help!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In either .NET MVC 5 or a .NET Core MVC application, is it possible to split your Models into a Data Transport Layer, your business logic into a Business Logic Layer and your Db Contexts into a Data Access Layer? I essentially would want the main project to really only have controllers that call to the BLL, and display the results in the view. That way there is portability with my application if I wanted to exchange the main project, which is essentially just a presentation layer.
I know I am going to be needing this kind of architecture as I am building an application that will share a lot of the same business logic between the two applications. What ways can I still get access to helpful features like scaffolding a model into views/controller, and still maintain that portability? Is there a way to do such a thing?
Please note, that this project may be on a short budget, so it is pretty essential to be able to maintain the scaffolding tooling.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
We have a web application for managing projecs, meeting etc in our company that is written in asp.net MVC . right now each department have their own copies. 5 department 5 copies. how can we make it as just one app and fix this?
by centralizing your database at a central location you can easly do it or by using microsoft sync framework you can easly sync data to one db to another
I would create a central mvc project, setup separate areas for each department, the source for each area into the main project.
You can also use each project as an area as outlined here:
http://nileshhirapra.blogspot.co.uk/2012/02/aspnet-mvc-pluggable-application.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have started to doubt my initial design decision, as everywhere I look I find tutorials on MVC where they just dump the access layer right into the MVC project. (Which goes against everything I've learned)
BarRepo: Handles access to an API.
FooRepo: Handles access to my Database (using EF).
FooBarHandler: Joins data from the two repos into useful data for the controller.
Controller: A controller, nothing speical.
As you can see in the picture, I've split up each part into their own project and try to obtain loose coupling. So I don't send Entity Framework classes out of the database layer and so on. However I've run into a bit of a pickle. The data amount fetched have become so large that it's noticeable on the frontend, so I needed to introduce paging. So I followed this tutorial.
My "problem" is that now MVC, Logic and the Database projects are depended on PagedList, so things aren't so neat and shiny anymore.
So my question is what would you have done?
You don't need to use PagedList as you can create a paged list of items yourself. Take a look at this StackOverflow question for an example of how to do this.
To summarise:
var pageNum = 3;
var pageSize = 20;
var pagedItems = data.Skip((pageNum - 1) * pageSize).Take(pageSize).ToList();
That way you will have no dependancies on PagedList, which will help reduce the coupling in your design.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I was wondering what would be the best strategy to implement a badges system using asp.net mvc. The one that stackoverflow has is pretty interesting. What do you suggest?
I guess I need to clarify the question a bit. The problem would be the different criteria for earning every badges. How do make that logic extensible?
I'd do it purely in T-SQL, and set up a SQL job that runs periodically (Jeff did it using C#, and has a goofy system where it runs the process based on a page request).
Basicly, in your SQL Job, scan your member tables and calculate if anyone is qualified for a badge, if so, update the badge table(s).
Then in the front end, do a query to retrieve new badges for a member on each request.