I've been working on a Web API solution that's separated on various projects, one of each is the API itself which contains the controllers and Views but all the Business Logic is done in all the other projects (being one of them responsible for all database iteration).
Now I want to apply Authentication using Identity which I wasn't familiar with but was able to understand a lot better thanks to this series of articles and so was able to get it to work on a test solution.
My question here is, how should I organize the different parts of the Identity implementation? Should I...
Make everything directly on the API project?
Create a separate project for all the Identity Implementation except for the controllers?
Use it some other way that you will suggest?
*If you suggest using different project, will I be able to pass the owin context between the projects? how?
Related
I've written all the classes and controllers for a web api to interact with a very large database (dozens of tables and controllers). I need to write a lot of small apps for specific tasks, as such, it would be idea if the controllers could also be a library file.
I've seen some old tutorials that suggest this is possible, but they no longer seem to work.
Could anyone please point me to somewhere that explains how this can be achieved; or, if there's a better best practices approach I should be taking.
Have all the object classes in their own library, and a working web app that interacts with the database. Want to extra the controllers into a library or include them in the existing object classes library.
By placing controllers in the library, do you mean having generic controllers so you can reuse them whenever you want for whatever model you need? Of so, you can check my library https://github.com/Ryukote/CoreGenerics which is also available on Nuget so you can add it to your project and use it as is.
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 am trying to create a good infrastructure for my web framework I am developing I have the following structure so far
solitude.admin web project to keep the controlers and views in how do I create this one I created a class libary but see you cannot have a web.config there
solitude.core will contain all my utililties and models
solitude.framework will be the core and meat of the cms platform my quesiton is how does one create a class libary project for asp.net mvc 4.6 to allow controllers and views to be shared i addded razor to a dll but i dont think that is correct approach
solitude.mvc this will contain the front end of the site i tried the below changing project guids to allow the sharing but its not working
I also changed the project type guids as suggested on aricltes on so but no joy I am trying to mimic our other platforms already work to futher my understanding.
<ProjectGuid>{152C761A-DD2E-4C1F-AF89-DFB2547A3BCA}</ProjectGuid>
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>solitude.admin</RootNamespace>
<AssemblyName>solitude.admin</AssemblyName>
<TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
Another point is if I was two have two sep projects admin and web how would one tell it to go to admin if user types www.domain.com/admin but yet be two independent web projects?.
I totally understand you. I'm in the same situation. I suggest you take a look at AREAS. I'm still learning it, but for what I've googled, it is the proper way to share views and controllers between projects.
This is one good link
I see good the separation of concerns. But have some questions:
1.- Why not making "solitude.admin" another web app project?
2.- Why aren't you using the expected naming conventions? That is a lot of lowercases you got there.
3.- Why would you like/need to share Controllers? Basically, there must be a
return View();
inside them.
For views, you could create some components based on parameters (which mostly, it comes to print out some HTML). You already have Shared Views but for the same project.
We are developing multiple applications for the same company.
The applications are distinct (so not suitable for a multi-tennant app) but there will be lots of shared models, a couple of shared controllers and ideally some shared views.
It is the first time I have had to do this, and wonder if I am approaching it correctly. Here is my plan:
Create a DB for the shared stuff, and another (per application) for application specific stuff
Each application will have 2 connections in web config
Create a DLL from the shared models and controllers. Put this in the /bin directory and reference it in the project. I want this to approximate the way a nuget package might work, and reference the
For each app create a SharedApplicationDBContext and a LocalApplicationDBContext, each accessing the respective DB.
Questions
Are the above steps the right ones to be taking?
Is there any way to include cshtml Views in a DLL?
Is it ok to include the Users controller / models in the DLL?
Are there any gotchas I should be aware of when sharing code like this over mutliple apps?
I know SO likes specific questions, and this is a bit vague, but I'm a bit out of my depth here and looking for some general guidance as to the right approach to take.
You've got the general idea, but it needs some tweaking:
Don't fool around with DLLs. If the projects exist in the same solution, then you might as well keep your class library there as well. In which case, you can just do a straight project reference. If you're dealing with multiple solutions then you package your class library as a nuget package and actually install it in each project. Creating a nuget package is easy enough, and you can either install from a local/network path or you can set up your own private nuget repo. This makes it stupidly easy to share resources, and you get the ability to publish updates and see at a glance which projects are running which versions of your class library.
Each app should only have the context that relates to its individual database. The shared database can also use a shared context, which would be contained in your class library. You should also house all your migrations related to this shared context in the same class library.
You can include views in a class library, but not as cshtml. They have to be compiled into the class library. You'll need RazorGenerator to accomplish this.
It's 100% okay to include the models related to users in your shared library. However, the controller is trickier. Unless you set up an SSO server that will alone be responsible for handling all authentication (a non-trivial task to say the least), each application will need it's own controller for authentication tasks. If all of the sites will reside on the same domain or subdomains thereof, you can easily share the auth cookie between them. However, if they will reside on entirely different domains, you can still share the same "users", by virtue of using the same database for each, but each site will require a separate login process (logging in at one does not log you in at another, even though the same credentials would work for both). The only way around that is, again, SSO.
For what concerns the views, you can include them in a DLL, please read here
For the models it's ok to have them in a different project.
For the controllers you can do it but you must let MVC know where the controllers will be located and you can do it by writing a custom ControllerFactory, please read more here.
I am new to MVC and Web API. I created two separate projects. One ASP.NET MVC 5 (MyUI) and other ASP.NET Web API 2 (MyApi). I would like to keep my API project separate from my UI layer.
The AccountController class in MVC project (MyUI) is essentially doing the same that the AccountController in the API project does (MyApi). I first thought about making the MyUI.AccountController a sub class of MyApi.AccountController but then I quickly realize that first inherits from Controller and second from ApiController type.
So my questions are:
In order to remove data access logic from MVC 5 project, should I
just convert the AccountController to a wrapper class which will
essentially call the corresponding methods from the
MyApi.AccountController?
Is there a better approach?
Edit:
Edit 2:
While trying to articulate the problem I realized that I was going about it incorrectly. My confusion came from the ASP.NET Identity implementations which were embedded within the API project. That needs to be moved to the Data Access layer and both controllers need to access them the same way which is a whole different can of worms :)
Thanks!!
Method 1 seems a plausible solution but what I would suggest is to create a new class library and there put your data logic. In that way, the MVC project and the Web Api project could connect to that class library.
The reason is that you never know if you write another UI layer, Service layer or other connectivity layer. All those layers could then connect to the same data logic layer.
Extract the common implementation into a separate project (a class library for instance). Your business logic must be the same no matter how you access it. After all, the web service and the site are only a view of the same information and the same control logic. In the future you might be required to write a fat client in WPF or a service in WCF and you do not want to rewrite everything, do you?
I think you are asking about layering application. basically the choice depends on requirements.If you are following data centric design check this layering
Research about DI,ORM,Repository Pattern, SOLID Principlese