去耦ASP.NET MVC 5的身份,让实施分层应用 [英] Decoupling ASP.NET MVC 5 Identity to allow implementing a layered application

查看:289
本文介绍了去耦ASP.NET MVC 5的身份,让实施分层应用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我新的ASP.NET MVC和我一直在发展与个人用户身份验证的MVC 5应用程序。做我的应用程序,如分离模型层,DAL层,回购,等等,等等,但是,当我一直在做一个分层的模式如今在MVC 5,我希望能够使用用户和角色管理和认证,他们称之为身份,然后仍然有层状结构,以我的应用程序,因为现在它似乎认同是非常再加上MVC项目本身在那里用户和角色模型和背景太pretty。

我在我的应用程序做,现在是我喜欢我的DAL,的UnitOfWork,回购,其他车型等在MVC项目中所有我认为,对被分开的层(单独的文件夹!)这只是为了工作,现在是这样。我知道这只是没有做正确的方式。

因此​​,谁能点我这个一些很好的例子或文章,或者直接解释,如果可能的话还是没有又如何?谷歌一直没有对我很好这一个。谢谢!


解决方案

下面是什么,我想尝试一个快速草案......我会创造这些图层:


  • Contoso.Core(类库)

  • Contoso.Data(类库)

  • Contoso.Service(类库)

  • Contoso.Web.Framework(类库)

  • Contoso.Web(ASP.NET MVC 5.0)

Contoso.Core:

这层对我的所有实体/班重新presenting我的数据库表。

因此​​,例如,我想有一个:


  • User.cs类。

  • Product.cs类

  • ProductDetail.cs类


有些人把这些实体/类:域对象,别人叫它POCO类

的任一个或这些实体/类在核心层,因为它们可能(或可能不)被其它层之间用来定义


Contoso.Data:

这一层是我定义我的 ContosoDbContext.cs 类。这是该文件,我有我所有的 DbSet&LT内部;> 定义。
因此,例如,我会在里面跟着我 ContosoDbContext.cs


  • 公共DbSet用户{搞定;组; }

  • 公共DbSet产品{搞定;组; }

  • 公共DbSet产品详情{搞定;组; }

不用说,Co​​ntoso.Data层将有 Contoso.Core 层上DEPENDECY。
此外,这是内部的,我有我的通用仓库 Contoso.Data 层和任何与数据访问。


Contoso.Service:

这层将在那里我把我所有的业务规则。例如,我可能有一个 UserService.cs 类,它可以有一个登录()方法。登录()方法会得到一个用户名/密码,并调用库来查找用户。

由于服务层所需要的库,我会在 Contoso.Data 层上的依赖,因为我将与User类被玩弄(这恰好住 Contoso.Core 层内),我也将使用 Contoso.Core 层上的依赖。


Contoso.Web.Framework:

这一层将有 Contoso.Core Contoso.Data的依赖和 Contoso.Service
我会用这个 Contoso.Web.Framework 层来配置我的依赖注入。


Contoso.Web:

最后一层时,MVC 5.0应用程序,会对依赖的 Contoso.Web.Framework 并在 Contoso.Service 并在 Contoso.Core 图层。

的控制器,将调用在 Contoso.Service 层中定义的类里面居住(例如登录()方法)方法。

在登录()方法可能会或可能不会,例如,返回一个User类(null或人口),并因为它返回用户类,并且因为我们是一个控制器里面,我们的 Contoso.Web 层需要的依赖关系的 Contoso.Service Contoso.Core


当然,我还没有详细的这里的一切,或每一层但是这仅仅是给你我会用建筑类型的例子。

到目前为止,我还没有回答你的问题,但很少有我了解MVC 5.0和它的新身份的机制,我相信 Contoso.Core 层需要在除 Microsoft.AspNet.Identity.Core Microsoft.AspNet.Identity.EntityFramework 的依赖p>

同样,我的 ContosoDbContext.cs 类需要实现这恰好属于 IdentityDbContext 接口 Microsoft.AspNet.Identity.EntityFramework.dll

这意味着我的 Contoso.Data 层会对 Microsoft.AspNet.Identity.EntityFramework 的依赖,最可能是 Microsoft.AspNet.Identity.Core ,以及...

正如你所说的,当你创建一个新的MVC 5.0项目,所有这一切都存在,且单个应用程序中定义。没有什么是或已被解耦成层。因此,在上述架构的 ContosoDbcontext.cs 类生活在 Contoso.Data 层内,而不是直接在ASP中。 NET MVC应用程序。

由于我没有尝试过的新的ASP.NET身份也没有我想围绕解耦的事情,我不知道如何诚实地回答你的问题。我猜你必须尝试和左右移动的东西。

如果当你做,请随时告诉我们如何去,什么是你遇到的事情/问题。

同时,我希望这有助于你一些线索(或没有)。

文斯

I'm new to ASP.NET MVC and I've been developing a MVC 5 application with individual user authentication. I've been doing a layered pattern when doing my applications like separating Model layer, DAL layer, Repos, etc. etc. but now in MVC 5, I want to be able to use the user and role management and authentication which they call Identity, and then still have that layered structure to my application because right now it seems Identity is pretty much coupled with the MVC project itself with the user and role models in there and the context too.

What I did in my application for now is I have all my supposed-to-be-separate layers like my DAL, UnitOfWork, Repos, other models, etc in the MVC project (in separate folders!) just to make it work, for now. And I know it's just not the right way to do it.

So can anyone point me to some good examples or articles about this or explain it directly if it's possible or not and how? Google hasn't been friendly to me about this one. Thanks!

解决方案

Here is a quick draft of what I'd try...I would create these layers:

  • Contoso.Core (Class Library)
  • Contoso.Data (Class Library)
  • Contoso.Service (Class Library)
  • Contoso.Web.Framework (Class Library)
  • Contoso.Web (ASP.NET MVC 5.0)

Contoso.Core:

This layer holds all my entities/classes representing my database TABLES.

So for example, I would have a:

  • User.cs class.
  • Product.cs class
  • ProductDetail.cs class
  • Etc..

Some people call these entities/classes: the Domain Objects, others call it the POCO classes.

Either or, these entities/classes are defined in the Core Layer since they may (or may not) be used amongst the other layers.


Contoso.Data:

This layer is where I define my ContosoDbContext.cs class. It is inside that file that I have all my DbSet<> defined. So for example, I would have the following inside my ContosoDbContext.cs:

  • public DbSet User { get; set; }
  • public DbSet Product { get; set; }
  • public DbSet ProductDetail { get; set; }

Needless to say, the Contoso.Data layer WILL HAVE A DEPENDECY on the Contoso.Core layer. In addition, it is inside that Contoso.Data layer that I would have my Generic Repository and anything related to "data access".


Contoso.Service:

This layer would be where I place all my business rules. For example, I may have a UserService.cs class that could have a Login() method. The Login() method would receive a username/password and call the Repository to lookup the user.

Because the Service layer needs the Repository, I WILL HAVE A DEPENDENCY on the Contoso.Data layer AND because I'll be playing around with the User class (which happens to live inside the Contoso.Core layer), I WILL ALSO HAVE A DEPENDENCY on the Contoso.Core layer.


Contoso.Web.Framework:

This layer would have a dependency on the Contoso.Core, Contoso.Data and Contoso.Service. I would use this Contoso.Web.Framework layer to configure my Dependency Injection.


Contoso.Web:

The final layer, the MVC 5.0 application, would have a dependency on the Contoso.Web.Framework AND on the Contoso.Service AND on the Contoso.Core layers.

The Controllers, would invoke methods living inside the classes defined in your Contoso.Service layer (for example the Login() method).

The Login() method may or may not, for example, return a User class (null or populated) and because it returns a User class AND BECAUSE we are inside a Controller, our Contoso.Web layer needs a dependency on the Contoso.Service and Contoso.Core.


Of course, I haven't detailed everything here or every layer but this is just to give you an example of the type of architecture I’d use.

So far, I haven't answered your question but with little I know about MVC 5.0 and its new Identity mechanism, I believe the Contoso.Core layer would need to have a dependency on Microsoft.AspNet.Identity.EntityFramework in addition to the Microsoft.AspNet.Identity.Core

Likewise, my ContosoDbContext.cs class would need to implement the IdentityDbContext interface which happens to belong to the Microsoft.AspNet.Identity.EntityFramework.dll.

This means my Contoso.Data layer would have a dependency on Microsoft.AspNet.Identity.EntityFramework and most probably the Microsoft.AspNet.Identity.Core as well...

As you say, when you create a new MVC 5.0 project, all of this exist and is defined within the single application. Nothing is or has been decoupled into layers. So in the above architecture the ContosoDbcontext.cs class lives inside the Contoso.Data layer and NOT directly inside the ASP.NET MVC application.

Since I haven't tried the new ASP.NET Identity nor have I tried to decouple things around, I wouldn't know how to honestly answer your question. I guess you'll have to try and move things around.

If and when you do, feel free to tell us how it went and what are the things/problems you encountered.

Meanwhile, I hope this has helped you shed some light (or not).

Vince

这篇关于去耦ASP.NET MVC 5的身份,让实施分层应用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆