I am trying to decouple the Identity model logic from an MVC project, as it appears in the standard template with Individual Identity.
I have created a class library and copied over the IdentityModels.cs file.
But as I am adding NuGet packages such as Microsoft.AspNet.Identity.EntityFramework to solve the missing references problems, the references list gets filled up with dlls that sound like web libraries, e.g. MS.Owin.Security.Cookies, Newtonsoft.Json, etc. Also, the IdentityModels.cs uses IdentityDbContext, which is contained in MS.AspNet.Identity.EntityFramework.
My question is: is it possible to completely remove the web-related dlls from the models project to make it "pure" models and business logic, (i.e. to have no references to cookies or Json or aspnet) or is the Identity Framework so tightly integrated with UI and browsers that it is best to leave it inside the MVC project?
Related
I currently have built an MVC solution which has a web project (controllers/views/scripts), services project (business layer, builds view models), and repositories project (data access layer).
I have used AutoMapper in my projects in the past and am trying to configure AutoMapper in this solution. Normally, I configure all of my maps in MapperConfig.cs which is called in Global.asax.cs.
My Problem is that the web project which is where I normally configure AutoMapper only has reference to the services project and the services project only has reference to the data project. So, when I go to configure my maps as I normally would, I am unable to define maps for the data project due to the web project not having a reference to the data project. I need a way to configure my data access layer maps without adding a reference for the data project to the web project.
The project dependency diagram would look like the following:
Web Proj --> Services Proj --> Data Proj
How can I overcome this?
There is no need to have a single mapping registration file across all projects, especially that you say that you don't have any cross-cutting types.
The simplest way would be to define a configuration file per project, and have those configurations call each other, repeating the layered dependencies of your assemblies, like below:
Global.asax.cs --> WebProjMapRegistrations.Register()-->ServicesMapRegistrations.Register()-->DataMapRegistrations.Register()
Alternatively, you could use the Assembly Scanning for auto configuration
As described by #Jimmy Bogard, when you run your web app, all assemblies of your application will eventually get loaded into your application domain - so you can get all the profiles from all the assemblies and add them to mapper config: How to Initialize AutoMapper Profiles in referenced project DLLs in ASP.Net webapp
Yet another alternative approach, that works for ASP.NET apps can be found here:
Where to place AutoMapper map registration in referenced dll
The way I've handled this in some ASP.Net MVC projects, is by using AutoMapper Profiles.
You create separate mapping Profiles that handle creating the Mappings for objects in that Project/Assembly.
You then add the profiles to the overall configuration manually, or you can use Reflection/Assembly scanning to automatically load the profiles.
I have a custom MVC 5 solution separated into 3 main projects, Data, Admin, and Public.
I need to add .NET Identity and it's related utilities.
I have read articles showing how to add it to an existing MVC project and I think I can handle that (basically add the dependencies/files).
My question is:
Does it make sense to add a Security project and put the related Identity stuff in there and reference from Admin/Web projects?
Or should it reside in the Data project since that's already referenced and handles the data?
Either way, how to implement Identity across the two sites? The Identity will be modified to include extra info about the user so it might make sense to be a part of the Data project...?
Also, how do I implement the identity/security project so i don't need to add Identity to each project? (Architecture is where I really need the help here)
Basically, how would I implement security as a separate project using asp.net Identity?
When I build an app like this I typically am using Dependency Injection, and have a project that defines my services call it Core (perhaps in your case Data?). In this project I'll typically create a ISecurityService interface that defines methods needed to get the logged in user:
public interface ISecurityService {
string GetCurrentUserName();
}
You might want to return more than a string, an object etc.. Then in when asp.net project that defines the functionality for ASP.net Identity I simply create an ASPNetSecurityService that implements ISecurityService and wire this into my IOC / Dependency Injection system. That way any class that has a need to get this info Can just request a reference to ISecurityService and the IOC system will provide them the registered ASPNetSecurityService.
Alternatively you can use this same technique and place the ASP.net in a separate project if you wanted to, but by using this DI technique you can keep the Identity Stuff in asp.net mvc but still make use of the functionality from anywhere you like.
Does this help?
I did something similar this year and it works as I had anticipated. I have the ASP.Net Identity as a project of it's own. It has been customized as well for my company to handle all business logic/rules around authenticating users. I set it up as a NuGet package and can install it into any web project to handle authentication to a common user store. The consuming applications do not need to know any of the details about authentication. The developer just calls provided methods.
The way I started was I created a project from the default MVC template and made note of all the dependencies that identity needed. Then I included those dependencies in my custom NuGet package.
You can create your own NuGet packages using NuGet Package Explorer: https://npe.codeplex.com/
I checked my notes and here are all the dependencies the I wrote down (it's possible I overlooked one) that would need to be added to the NuGet Package:
NuGet Packages:
ASP.Net Identity Core
ASP.Net Identity Owin
ASP.Net Identity EntityFramework
Microsoft.Owin.Host.SystemWeb
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.MicrosoftAccount
Microsoft.Owin.Security.Twitter
Add references:
System.Configuration
System.Web
System.Web.Helpers
Hope this helps!
I have three parts of a project, one is Core(bussiness) project, one is webproject and the last is the test project.
I want to call some classes that I saved in one folder from core project to webproject without calling the dll of the core project. Since core project is already refereed into the webproject. So it will call the cycling if the references and not allow me to do that.
How I can use classes from core project to web project without call the DLL?
I Have already tried 'using', The code is following. It's not working for me.
using BlogEngine.Core.API.PageML; // I need to call all classes from this folder
using BlogPage = BlogEngine.Core.API.PageML;
namespace admin.Settings
{
public partial class DownloadInsertPage : System.Web.UI.Page{
protected void BtnPageMLInsertClick(object sender, EventArgs e)
{
var reader = new PageReaders(); // the class, I want to call from the core project
}
}
Thanks
Your question is unclear ("since web project is already refereed into the webproject" for example) but you should really make the web project have a reference to the core project, but not the other way round. The core business logic shouldn't know about your web "view" onto it, but the web project should absolutely know about the core business classes.
If you have classes in the web project which you're currently referring to from the core project, you should probably move them to the core project - or to a third project which both of the other projects refer to, if they don't logically belong in the core project itself.
Your model may benefit from contract interfaces - that would help you redesign your current model in order to avoid circular references. Here's some posts about this:
a design to avoid circular reference in this scenario
Resolving Circular References (C#)
Now, I may have misunderstood your question, and you'd rather benefit more from learning about add-on models. In that case, this post may be of some help:
C# Plugin Architecture with interfaces share between plugins
You cannot.
If you need these classes to be accessible in both assembly, you should create a third one that would be referenced by both of them although this should be reserved to cross-cutting concerns only (e.g. logging logic).
Thank you guys for your valuable comments..
I want to share, what was the problem and how I resolved it.
I build the core project after created some classes into the PageML folder and build it without calling this folder into the web project. and update the reference(dll) of core project in the webproject. and it's working for me.
Thank you All
Keep clam and do coding.
:) have a nice time
I have a MVC4 project which is going to be a large system, I want to split the database management into its own project so in my solution I will have MyMVC4 and MyMVC4_Data
I will add MyMVC4_Data as a reference to the main MyMVC4 project. I believe there will be multiple projects in the future so splitting the data makes sense.
My question is, what sort of project template will be sufficient for the database stuff, all it will have is Linq and manager classes for each table to insert delete etc. I don't think it would be necessary to include a new MVC4 project as the overheads will be too big for what is needed. The project must be referable by the main project
Any suggestions would be appreciated
Thanks
I'd use a Class Library project. From the docs:
You can use the Class Library template to quickly create reusable classes and components that can be shared with other projects.
I'm using EntityFramework 4 in my WPF desktop-application (NS: MyCompany.MyProduct).
Now I want to create the same application in ASP.NET (NS: MyCompany.MyProduct2), with the exact same functionality... Hence I need to use the exact same database as the WPF application already does.
Additionally, I want to create a new executable (hence a new wpf project) on top of my primary WPF project, that also uses the same ConnectionString like the WPF / ASP.NET-Application, to display some reports.
So I figured out I'd need to share the .edmx-Model (NS: MyCompany.MyProduct.Models.DBModel.edmx) and the ConnectionString that is already persistent in the app.config of the WPF app or the web.config of the ASP.NET-App.
What is the best or recommended way to do this?
What is the best or recommended way to do this?
Create a class library project and put EF model in there and share it between your WPF/Web projects. The app.config file of a library project isn't picked up by the parent project therefore you will have to manually update your web.config file to add the ConnectionString section.
This approach allows you to share business logic between your WPF app & your web app. If they are essentially the same app but on different platforms, then you should only be re-implementing the UI - this is one of the major advantages of the MVC pattern.
Agree with #James here. Don't be afraid of adding library projects to your solution. So you would have a project called MyCompany.Model that contains your EDMX. (Actually, you might find later that you want to use the T4 generation to split your model off from your DbContext or ObjectContext, but that's another discussion.)
With Visual Studio you can actually add a project--your EDMX project--to more than one solution. Be careful not to make changes to the EDMX project when editing one solution that break the other, though.
Respectfully, you may find that it's not ideal to use the GAC here, especially if your EDMX is still evolving.
As for connection strings, these are one thing that you tend not to share between projects. Typically they are in the app.config (or web.config) for your executable project. This can be a gotcha, because if you use a library project to hold your EDMX, EF will automatically create an app.config in the library project, with the connection string in it. But .NET never uses an app.config for a DLL. The only reason it's there is to give you something you can copy/paste into the real app.config for your executable (WPF) app.config or the web.config.
If your goal is to share the single .edmx dll between all three applications on one machine, the best way to accomplish this is to sign the dll, then add it to the GAC. If the dll will remain on different servers, there is no need to GAC the dll, you can just reference it in your projects, and add the connectionstring entry in the respective .configs.
GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.100).aspx
Install a DLL to the GAC: http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx