洋葱体系结构、项目架构和认证

Question

作为我学习的一部分，我正在学习ASP.NET MVC和Web，并试图为我的一个测试项目实现带有存储模式的洋葱体系结构。

我以前开发过单一的MVC项目，但没有使用分层和洋葱。

我的想法是使用单一的Web将数据提供给不同的客户端(Web 5、Xamarin - Android)。

下面是我试图遵循的模式/结构：

1. 核心工程
   • 实体
   • DTO's
   • RepositoryInterface(GenericRepository +个人InterfaceRepository)

2. 基础设施工程
   • 存储库(实现RepositoryInterfaces)
   • 迁移(代码第一工作流EF 6)
   • 映射(使用AutoMapper)
   • DbContext.cs

3. 测试项目(NUnit)
4. WebApi 2项目
   • 带有UnityDI的控制器
   • 基于令牌的认证(？)

5. MVC 5项目
   • 管制员须发表意见
   • 用户认证(?)

6. Xamarin项目

我的问题如下-

1)我往正确的方向走吗？

2)在使用存储库模式时不使用UnitOfWork可以吗？

3)我真的很困惑于身份验证。我应该如何认证我的用户和网络api？我的应用程序中的用户表单身份验证？以及基于web api的令牌？

欢迎任何建议/链接/建议。

Answer 1

1)我往正确的方向走吗？

这是一个过于宽泛的问题，如果你想用任何细节来回答的话。我们不知道你目前的经历是什么，也不知道这里是否有值得学习的东西。

乍一看，你列出的清单看上去并没有错，但有很多方法可以让你做错事。

我见过无数的开发人员在没有真正理解其目的的情况下遵循某种结构(例如，层分离和SRP)，最终导致他们的抽象在层间大量泄漏。同样的事情也可能发生在这里，我不知道，所以我害怕告诉你这绝对是件好事。

2)在使用存储库模式时不使用UnitOfWork可以吗？

简而言之:我以前创建过没有工作单元的存储库，但是一旦代码达到了除了简单的CRUD操作之外的任何级别，您将后悔没有实现UoW。我建议实现UoW，除非您知道应用程序永远不会处理任何复杂的逻辑或事务。

存储库模式有一个很大的缺点。我忽略了架构师级别的关注点，我只是在讨论您似乎所处的层次上的问题。

存储库的最大缺点是它们有自己的数据文本。当您的操作总是集中在一个特定的实体(或域模块)时，这不是一个问题，但是当您一次开始处理多个实体类型(例如一个复杂的报告，或者创建多个实体类型的导入方法)时，这个问题就变得更加相关。

首先，将检索所有Foo对象及其相关Bar对象的代码放在哪里？FooRepository？BarRepository？你会发现这里有很多分歧。无论您选择哪一个位置，一些开发人员都会期望它位于另一个位置，或者认为应该将它完全放在第三个位置。

其次，存储库(没有工作单元)会使您失去跨几种类型的事务完整性。假设您有一个导入，它应该创建3个对象( Foo、Bar和Baz )。但是，如果任何这些操作都失败了，则需要确保没有保存任何项。

如果没有一个工作单元，您的FooRepository将有一个与您的BarRepository不同的数据文本，这导致无法确保将这两个/没有一个项保存到数据库中。

但是，一个工作单元可以确保您的所有存储库(位于同一个uow对象中)共享相同的数据文本，因此可以保留传输完整性。

还有实现事务完整性的其他解决方案，但它们往往很脏，而且明显不如UoW实现。

3)我真的很困惑于身份验证。我应该如何认证我的用户和网络api？我的应用程序中的用户表单身份验证？以及基于web api的令牌？

这在很大程度上取决于你想要实现什么。谁将是你的最终用户？随机的人？某个公司的员工？用户是否需要在应用程序上进行身份验证，而不仅仅是使应用程序可以自由访问，还需要将所有信息锁定在同一个API后面？是否需要脱机身份验证和/或访问资源？

这里没有一个答案。这需要你方做更多的解释，这应该是一个单独的问题。