Entity Framework User and Role Management [closed] - c#

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.

Related

Should I use different services for a different area in ASP.NET core? [closed]

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)

The right ASP.NET boilerplate best practice [closed]

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 just found about the ASP.NET boilerplate framework for ASP.NET Core applications. The boilerplate is cool, it has all the necessary structure we need in order to create a SOLID proof web application.
My question is that, as per the site I have to create entity models in .Core project, and Dto's in Application project but as I can see these Question, and Answers are different entities but they kept both of them in the same folder and same namespace.
It does not look like a good practice, can anyone tell me is it wrong to keep these related entities in the same namespace/folder or it's ok to do so?
You can locate entities/services into any namespace. This is not related to the framework actually.
Question/Answer application is very simple project where there are just 2 entities. I thought that Question is aggregate root and answer is a child entity (they are a single aggregate together). This is why I put them into same namespace.
I suggest to follow "namespace per aggregate" principle, but "namespace per entity" is also fine.
BTW, #Dongdone, AspNet Boilerplate is completely open source & free. We have a another product, AspNet Zero (https://aspnetzero.com) that is commerical and developed on top of the ABP framework. But that does not make the ABP framework a paid tool. It's absolutely open source & free.

Best way to create same file structures in visual studio [closed]

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 huge EF MVC solution where there are separate projects for data models, services (interfaces and their implementations) and repositories. It is necessary to create new files with given structures, e.g.: different using, namespaces, etc.
Example
New database table is created with the following names:
SomesSession
SomeQuestions
SomeAnswers
SomeScores
Four files under the Models project, four files under Services - Interfaces, four files Services (where implementing the interfaces), four files under Repositories.
Is there or what is the best way to make automatic this tedious task?
Maybe Visual studio macros?
Out-of-the-box Visual Studio templating to generate code on Entity Framework and many other frameworks is implemented using T4.
Check this MSDN article to learn more about how to implement these code generation templates from scratch:
Code Generation and T4 Text Templates

Asp.NET MVC/Web API's pattern meet SignalR/Websockets [closed]

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

3 layer architecture in asp.net [closed]

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 starting a project in asp.net. I want to use 3 layer architecture. now I have problem with layers. I manage these layers like this:
but I have seen somewhere that uses App_Code and some other formats. could you please help me which one is true and standard?
App_Code is a special ASP.NET folder which is used by ASP.NET Websites. It is not used by precompiled ASP.NET applications. You can read more about the differences between the two in this article. So if UI is an ASP.NET Website you could use the App_Code folder to put some logic although this is better suited to external libraries as you have in your current design. This allows for better unit testability of this code and reusability.
Avoid the use of App_Code. Anything you put in here doesn't compile until the site is executed. Any dependency that your forms and user controls have is best put into your UI layer, outside of the main web folder. You'll have a lot more peace with objects that are compiled early rather than later.
Now-a-days I see this standard a lot:
ProjectName
-ProjectName.Core (All poco classes and interfaces)
-ProjectName.Data (All entity framework stuff)
-ProjectName.Service (All business logic)
-ProjectName.Web (All font end logic)
"Core" is reference in all projects to move data around.
"Data" is referenced only in "Service".
"Service" is referenced only in "Web".

Categories