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
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 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 3 years ago.
Improve this question
new job, new giant website made of multiple solutions, I have to develop a new page:
I'm in solution A, I want to load a view in solution B... How does this work, its my first experience with multiple solutions websites.
both solutions are in asp.net c# mvc
Presumably you are working within an existing codebase with plenty of examples? This question is fairly vague, but my assumption would be that your views are being routed by a controller which determines the URL of the page. I can't tell based on your tags though.
If this is the case, then it doesn't matter how many projects are running as long as you hit that URL. The controller acts as an API and will handle the request as long as that project is running. At my job we run a composite application using ASP.NET Core with a dedicated "content discovery" project which acts as a middleware API for handling all route requests from all (and we have a lot) of our various projects that are working together but it doesn't need to be that complicated.
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).
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 9 years ago.
Improve this question
I am creating a asp.net mvc2 project which contains multiple modules in the project.I am thinking to create supprate controller for each module, but i want to know what are the advantages & disadvantages out of it?
Seperate controllers means a Seperation of Concerns, you would have separate controllers to handle logic that should be separated. So you won't get a cluttered controller handling everything in your application. Besides clarity in your application, this brings the benefit that if you need to change one thing, you don't break other code handling other logic in the same place.
Naturally this separation is also present in your Views folder, so you'd have clear oversight what's going on where in your app.
Also, if you have a lot of dependencies that your one controller needs (like services getting different domain models) you would have these listed in one place, which would make it less clear what the primarily function of that controller is. It's nicer to have more controllers with less dependencies each.
Another benefit is that you get user friendly Urls without much effort:
www.domain.com\home\index
Pretty much spells out this is the homepage.
And:
www.domain.com\account\login
does so too.
Basically, make objects (controllers) for each "section" of your web app, like you would make objects for each functionality of the business logic.
i would read this article: Biggest advantage to using ASP.Net MVC vs web forms
since it already covered your question for a big part.