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 6 years ago.
Improve this question
Given a 3-layer architecture:
Domain Logic Layer
Data Access Layer
User Interface Layer (ASP.NET MVC web app)
What is the correct location for placing the logic related to constructing a custom user identity, adding custom Claims, and signing it into the web application?
For example, logic like this:
if (something)
customClaim = new Claim("MyClaimType1", "SomeClaimValue");
else
customClaim = new Claim("MyClaimType2", "AnotherClaimValue");
customClaimsIdentity.AddClaim(customClaim);
HttpContext.Current.GetOwinContext().Authentication.SignIn(customClaimsIdentity);
I want to say the UI layer, but isn't the custom logic (i.e. custom user) something of a domain thing? Little confused here...
What you are describing is a security cross-cutting concern usually associated with ASP.NET MVC and is usually implemented as an action filter. Based on that then the code you displayed, which also makes direct use of the HttpContext should be in the User Interface Layer (ASP.NET MVC web app).
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 5 months ago.
Improve this question
So, I am using a classic MVC architecture with a service layer for my ASP.NET core app.
I added an Admin area and in it I added Controllers, Models and Views folders, so I can easily separate the admin-related stuff from the general user-related stuff. Now I have two options:
Creating a Services folder in my Admin area and literaly copy-pasting the already created services, but from my general Services folder
Directly using the already created services from the general Services folder
I am not sure which approach is generally accepted as better, so I hope for some guidance.
If you can use it as is, then the general Service folder is enough, but if you need to change/add many things than it is a good idea to create a separate service. (You can still use the general Service as a dependency in your admin service)
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 7 years ago.
Improve this question
We have a Web Application that wants to make use of SignalR/Websockets in Asp.NET MVC. I am having difficulty understanding where the SignalR and/or Websockets end up in the directory structure that most the make sense and keeps to the separation of concerns (since SignalR/Websocket functions are technically like controllers).
So, is this more correct?
Controllers
Model
Views
Roles
Or is this more correct?
Controllers
Roles (subfolder)
Views
Model
Second question: does it make sense to name it "Roles"? Or is this a case of where we call the Folder SignalR?
The reason why I ask is that there has been a lot of emphasis on directory structure of MVC applications, (Models, Views, etc), but there does not seem to be much direction on where to put the Roles classes.
If you are using SignalR 2 and you will use the Hubs the best way to manage es using:
Models
Views
Controllers
Hubs
In the Hubs folder you should create all the elements related to Microsoft.AspNet.SignalR.Hubs like this:
namespace MyApp.Hubs
{
using Microsoft.AspNet.SignalR;
public class MyHub : Hub
{
}
}
you can see a sample here:
http://www.asp.net/signalr/overview/getting-started/real-time-web-applications-with-signalr
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 7 years ago.
Improve this question
We have developed an asp.net mvc application and is live for 2 years.
Now our client is asking for Audit Trail.
Requirement
Should be able to define which column / table needs to be audited
Should be able to create a report based on the same.
Below is our current scenario
We are using SQL Server 2012 as backend
Our data access layer communicated to DB only through Store Procedure.
We are not using any model binders.
What is the best way to implement audit trail in the current scenario?
Define the business scenarios that need to be audited.
Identify the code entry points where those scenarios happen
Design the audit data model based on what data you want/need to store
Write data in your audit table/tables on the previously identified code entry points
This answer is intentionally vague. Auditing is not something that ASP.NET or any framework can do for you. This is usually intimately related to your business logic code and requirements
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 7 years ago.
Improve this question
I have a Visual Studio solution which contains several projects :
Domain classes
Data access layer - which contains DB context
MVC application.
The MVC application by default uses existing classes for user management and it also has his own ApplicationDbContext. In this case we have two DB contexts.
What is your experience regarding the user management ? Would it be better if I create my own classes for user management and place them to the Domain Classes project. I think it would be much easier latter for maintaining and in this case there will be only one DBContext. Another possible problem can be relations between existing ApplicationUsers(from the MVC project model) and classes from the Domain Classes Project. Or maybe to move the ApplicationUser class definition to the DomainClasses project ?
I highly recommend MembershipReboot. You have the option of using its built in UserAccount or using your own.
On a side note Brock is part of Thinktecture. In one of the asp.net stand-ups it was mentioned that the team may just recommend a 3rd-party identity provider instead of role their own. That was my understanding but maybe I am just being hopeful. I think it was this one https://www.youtube.com/watch?v=CMTd5yS-yFE&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=2 but don't hold me to that.
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
My MVC's controller actions are getting huge. I want to create a service layer so that I can move code there. The idea is to use the SOLID principle: the controllers use the service layer to get the domain models that will be then transformed into view models.
My question is simple: Should my service layer be a new assembly (project) that will go along with my MVC project or should it be simply a class inside my already existing assembly (MVC Project)?
My approach will be similar to the following one, but unfortunately the post doesn't explain exactly how was the service layer defined:
http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I would consider making the service layer a separate thing.
Service can be an interface-based object that is implemented either in-memory in the application or distributed and accessed remotely via SOAP, REST, RCP-XML, or anything else. The controller/client need not know or care if they have a client program that's interface based as well.
A dependency injection, interface based solution would allow you to inject client and service implementations in pairs so controllers need not be disturbed if you change how to access the services.
Controller is usually closely tied to a view. Views come and go, but services tend to remain. Services should map to business functionality that could be shared across applications.
Should my service layer be a new assembly (project)
Yes, it should. Other UIs might want to use it in the future...