I have just created a new asp.net mvc 5 project, but would like to abstract all of the identity logic into it's own project. I did something like this with asp.net identity 1.0, but through lack of understanding or otherwise, found it less than ideal as it appeared that I needed to duplicate several references for each project as well as the entity framework connection string to get it to work. I tried this same tactic with the latest version of identity 2.0 with no success. So is there a suggested way to do this, or is it better to just keep all the identity logic in the main mvc startup project?
There should be nothing preventing you from writing a shared class library that abstracts identity apis for you. Your MVC app would depend on the shared class library and use any apis exposed there, while your class library can reference identity (or whatever else you want) to implement its functionality.
Related
I'm creating application with layered architecture. I have separate
+ 'DataModel' project with only model classes
+ 'BusinessLogic' project that containing my business
+ 'Core' project for run Business from ui
+ 'ViewModel' project
+ 'Web' project with asp.net core application.
My goal was to separate these projects so that Web project knows nothing about DataModel so the Web project should just reference Core and ViewModel. Everything was great until I configured Asp.Net Identity - in order to configure authorization I had to reference DataModel project which I had wanted to avoid. Is it possible to achieve my goal, and (if so) how to do it.
Note:
I'm using this how to separate model library when using asp.net identity for writing my question and i don't find accepted answer as my answer!
When you create a website that uses Identity directly, you must provide it with various Identity "stores": UserStore<TUser>, RoleStore<TRole>, etc. The default and easiest approach is to use Entity Framework Core as the backing for the store(s), and Identity comes with built-in stores to work with EF Core. However, using that requires access to the context, which means you then will need a dependency on your data layer. There is no way around that when using AddEntityFrameworkStores<TContext>.
If you want to keep your data layer abstracted, then you will need to either 1) use a centralized identity provider, such as IdentityServer or 2) create custom stores.
IdentityServer, for example, supports using both EF and Identity as a backing. That does mean it will need a dependency on your data layer, but IdentityServer would be exist in a separate project. Your actual website would handle auth via IdentityServer endpoints, and therefore would have no dependency on your data layer. In fact, it doesn't even know or care that you're using Identity at all at that point.
Creating custom stores will be a bit more difficult, obviously, and unless you provide an true abstraction layer, you'll still ultimately end up with a dependency on your data layer. That might be something like a microservice(s), where the store will actually make HTTP requests to the service to get the objects it needs, instead of making database queries directly. The microservices, then, will hold the data dependency.
One thing you might not be considering in this is that the dependency is there even without a direct reference. For example, if your Core project uses stuff from your DataModel project, and then your Web project uses stuff from your Core project, your web project has an implicit dependency on your DataModel project. If you look at the bin folder after building, for example, you're see a DLL for your DataModel project and even one for EF Core there, despite not explictly using either one in your Web project. In this case, using separate projects helps only to division the logic in perhaps a more succinct and understandable way, but it does not serve to actually abstract any dependencies.
I recently came across an awesome NuGet package, called Hangfire, which enables using background processes in an ASP.NET MVC project. What is interesting about the package though, is that it automatically sets up a nice dashboard subpage (accessible through http://your.url/hangfire) and creates new tables in your database.
I wonder, is it possible to create a whole web solution from optional packages, like Hangfire? Like I would create just a simple home page and all other subpages would be optionally installed via a config file, or in the somewhere in the App_Start? I believe it should be very easy with the new .NET Core 5 and the Startup.cs class (since also SignalR has a Startup.cs class and is then available via http://your.url/signalr/hubs). However, I was unable to find any proper tutorial. Could somebody point me in the right direction?
Solution Structure:
MyProject - WEBAPI
MyProject.CORE - Class Library
MyProject.Models - Class Library
MyProject.DAL - Class Library
Project References:
MyProject refers to CORE , MODELS
MyProject.CORE refers to DAL,MODELS
MyProject.DAL refers to MODELS
Project Description:
I am trying to create an application with ASP.NET MVC WEB API . so that I can call my API in future mobile applications. My idea behind this layered architecture is WEB API project will hold the front end views of my desktop application and call's the API controller methods on button click events . The event handler methods in API controller will call the Methods in the CORE project where I will implement the business logic.Then the call will be going to DAL where I will call the DB Stored Procs to insert data. As MODELS project is referred to the rest 3 , I will be able to transfer Objects across them.
Here are my questions below.
1) Can I use the same web API project above to create views of my desktop application and call the API controller methods on events like button click?
2) I don't want to expose the implementation of my business logic in CORE application to any other referencing projects. But still i need to follow a layered architecture.
How can i achieve that. Please explain with an example.
3) Is there any best architecture that i can follow with the above requirements.
4) Is this a valid architecture for WEB API and will this work?
Please take the Model example as UserModel {Name, Password, Email}
I assume you meant 'solution', not 'project'. Yes, you can keep mixed types of projects inside one solution, that is Web API for IIS hosting and WPF app that references your core.
This is where interfaces and dependency injection come into play. Create separate interface project to reference and use some dependency binding module like ninject or Microsoft Locator
When following any architecture pattern, remember that patterns were created for developers, not the other way round. What am trying to say, that when you follow any architecture, you - and only you - know what you are trying to achieve. Don't stick to any pattern if you don't know what are you doing and feel free to bend any pattern to your needs. For now keep it simple.
Yes.
My team is working on a new project that is built on the ASP.NET Core Web Application (.NET Framework) template. For legacy reasons we have another project that was build upon System.Web and directly accesses HttpContext via HttpContext.Current. Since our new project uses Microsoft.AspNetCore.Http.HttpContext we would like to know if its possible to convert the HttpContext to the older System.Web.HttpContext?
'Legacy' ASP.NET and ASP.NET Core don't play well together. In fact, I'd be surprised if they do at all. Their nature and characteristics are very different. Mocking the HttpContext in the legacy ASP.NET is pretty difficult. And even if you could, it's gonna be a hell of a job to set it correctly in the HttpContext.Current without being bitten by multi-threading issues.
My suggestion is to migrate the legacy application or expose the legacy functionality via a web API and use that to communicate between the two applications.
With ASP.NET 4.5 it is possible to use Assembly.Load() or AppDomain.CurrentDomain.Load() to dynamically load an assembly at runtime. This can be used to add new functionality to a running web application in the form of modules without having to rebuild or even restart the app.
I would like to know how this can be done with the new ASP.NET vNext (5.0?) targeting the Core framework. I know this can be done with the full framework as System.AppDomain is available along with an overloaded Assembly.Load(). When I change to target the Core framework, I no longer have System.AppDomain available and Assembly.Load() becomes limited.
Is there a way to get this dynamic modular functionality in the ASP.NET 5.0 Core framework?
I'm not sure what a good answer would be, because Asp.Net 5 is so new, and doesn't have a lot of full documentation.
It should theoretically be possible, it'll just be different than what you're used to.
Looking at the source there is an interface IAssemblyLoadContext which will allow you to get the assembly. There is also IAssemblyLoader.
These are used by the "kre" host, which is the underlying piece of Asp.Net 5 that basically boostraps your application. So you would need to add your IAssemblyLoader to the underlying host, so that the kre.
Unfortunately I'm not seeing very many extension points in the code as of yet. Will we be getting those extension points? I do not know. You can log an issue on the github page. It's also possible there is an extension point I'm not seeing currently.
To come back to the question, can you add that kind of extensiblity to Asp.Net 5 Core? Yes, you could create your own host, similar to the default host, that would then include your custom loader, and then start your application with that.
You can try ExtCore framework
It allows to have modular and extendable ASP.NET 5 applications out of the box.
In short
It allows to use both modules from dlls and from nuget packages at the same time.
It allows all modules to work with storage in the single context and to have their own models and repositories.
Every extension can have controllers, views, static content etc.