标签: onion-architecture

我正在尝试在我的ASP.NET MVC 5解决方案中实现Identity 2.0,该解决方案遵循洋葱架构.

我有一个ApplicationUser核心.

namespace Core.DomainModel
{
    public class ApplicationUser {...}
}

在我的数据访问层中,我正在使用实体框架6.1,我的上下文源于IdentityDbContext此处,并且在此处存在问题.ApplicationUser需要从中衍生出来Microsoft.AspNet.Identity.EntityFramework.IdentityUser

namespace Infrastructure.DAL
{
    public class TestContext : IdentityDbContext<ApplicationUser> {...}
}

我的域名模型不应该引用Microsoft.AspNet.Identity.EntityFramework违背洋葱的想法.

什么是好的解决方案？

我正在学习洋葱建筑.我对服务层感到困惑,因为我看到有些人说核心层应该只包含:

• 楷模
• 存储库接口
• 服务接口

但其他人表示它也应该实现服务接口.那么什么层应该实现服务接口？

我认为基础设施层应该实现:

• 存储库接口
• 服务接口

并在请求时将它们注入UI层和测试层.

谢谢!

我正在使用存储库模式来提供对聚合的访问和保存.

问题是更新由实体关系组成的聚合.

例如,采取Order和OrderItem关系.聚合根Order管理自己的OrderItem集合.OrderRepository因此,一个人将负责更新整个聚合(没有OrderItemRepository).

使用Entity Framework 6处理数据持久性.

更新存储库方法(DbContext.SaveChanges()在别处发生):

public void Update(TDataEntity item)
{
    var entry = context.Entry<TDataEntity>(item);

    if (entry.State == EntityState.Detached)
    {
        var set = context.Set<TDataEntity>();

        TDataEntity attachedEntity = set.Local.SingleOrDefault(e => e.Id.Equals(item.Id));

        if (attachedEntity != null)
        {
            // If the identity is already attached, rather set the state values
            var attachedEntry = context.Entry(attachedEntity);
            attachedEntry.CurrentValues.SetValues(item);
        }
        else
        {
            entry.State = EntityState.Modified;
        }
    }
}

在上面的示例中,仅Order更新实体,而不更新其关联的OrderItem …

假设我有两个有界的上下文,即Shipping Context和Billing Context.这些背景中的每一个都需要了解客户.

在数据级别,客户由CustomerTbl数据库中的表表示.该表包含描述客户的所有必要列.

CustomerTbl(简化)中的列:

• Name
• PhysicalAddress
• PaymentMethod

该装运情境关注的是Name和PhysicalAddress而计费上下文关注的是Name和PaymentMethod.

在装运背景中,我已对聚合建模Recipient:

• Recipient现在有属性/值对的对象Name和PhysicalAddress

在结算上下文中,我已对聚合建模Payer:

• Payer具有属性/值对的对象Name和PaymentMethod

两者Recipient和Payer聚合都完全由上下文边界分隔.他们也有自己的存储库.

问题:

1. 是否可以使用相同的"数据库表"来拥有多个聚合(假设它们位于不同的有界上下文中)？

2. 在更多有限的背景下可能需要客户数据.这不意味着每个有界上下文的许多聚合,存储库和工厂实现吗？代码中会有一定程度的冗余.这不会影响可维护性吗？

3. 跨聚合共享属性是否可以接受？一个例子是客户Name财产.这也意味着冗余的验证码？

我首先使用Entity Framework 6数据库.我正在转换该项目以实施洋葱架构,以便更好地分离关注点.我阅读了很多文章并观看了很多视频,但在决定我的解决方案结构时遇到了一些问题.

我有4个项目:核心,基础设施,网络和测试.

根据我的了解,.edmx文件应放在我的"Infrastructure"文件夹下.但是,我还阅读了有关使用Repository和Unit of Work模式来帮助EF解耦和使用依赖注入的信息.

有了这个说:

• 我是否必须在CORE下为模型中的所有实体创建存储库接口？如果是这样,如何在庞大的数据库中维护这个？我已经研究过自动播放器,但发现了IEnumererables与IQueryables有关的问题,但有一个扩展可用它必须与此一起发布.我可以更深入地尝试这条路线但是想先听一听.

• 作为替代方案,我应该将我的edmx保留在Infrastructure中并将我的实体的.tt T4文件移动到CORE吗？这是否存在紧密耦合或良好的解决方案？

• 通用存储库界面是否适用于您提供的建议？或者EF6已经解决了Repository和UoW模式问题？

感谢您查看我的问题,并提出任何其他回复.

我在这里发现了一个类似的帖子没有回答: EF6和Onion架构 - 数据库优先,没有Repository模式

我想开始使用 NestJs 创建 REST API，但我不确定如何设置可扩展的层通信对象。

因此，从有关如何开始的文档中，我提出了UsersController处理 HTTP 请求和响应的方法，UsersService处理控制器和数据库访问器之间的逻辑以及UsersRepository负责数据库管理的方法。

我使用NestJs提供的TypeORM 包，所以我的数据库模型是

@Entity('User')
export class UserEntity extends BaseEntity {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column({ unique: true })
  username: string;

  @Column()
  passwordHash: string;

  @Column()
  passwordSalt: string;
}

但是您可能知道，这个模型必须映射到其他模型，反之亦然，因为您不想将密码信息发送回客户端。我将尝试用一个简单的例子来描述我的 API 流程：

控制器

首先，我有一个用于GET /users/:id和的控制器端点POST /users。

  @Get(':id')
  findById(@Param() findByIdParamsDTO: FindByIdParamsDTO): Promise<UserDTO> {
    // find user by id and return it
  }

  @Post()
  create(@Body() createUserBodyDTO: CreateUserBodyDTO): Promise<UserDTO> {
    // create a …

的洋葱结构是结构化的应用程序的方式来保持(例如在项目:关注和松耦合的分离http://onionarch.codeplex.com/).依赖注入/解析是此体系结构的一个关键方面,因为它用于将所有层绑定在一起.

上面的链接包含一个关于如何使用Onion分层构建ASP.NET MVC的示例应用程序.我非常喜欢它,但是大多数这些例子都使用了Ninject(我们都知道它很慢).我想知道是否有人可以详细说明如何将不同的DI工具(如SimpleInjector,Unity或Autofac)集成到洋葱项目中.

关键是所有层只有1个依赖关系(包括MVC项目),即Core层.除依赖性分辨率图层外,该图层可以引用所有图层.

我很难将MVC项目设置为启动项目,使用DI,而不是在MVC层中包含对DI工具的引用.

我目前正在研究域驱动设计,并尝试将其应用于WPF项目.我观看了一些教程视频,并阅读了很多文章,例如:

• 同一层中的洋葱架构依赖关系:基础架构和Web通信
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• 域驱动设计:域服务,应用服务

我理解对接口和控制反转的关注.我读到有一些经常出现的层名称(域/核心用于表示知识领域,基础设施用于持久性,应用程序用于......我不明白),但它们会根据我阅读的文章而改变.有些人甚至没有出现.

是否有可能拥有一个理论上在洋葱架构中需要面对所有需求和问题的所有层的列表,它们的意图(它们包含什么样的代码,它们试图满足什么样的需要) ,他们需要参考哪一层),好吗？

我使用这个示例项目(https://github.com/imranbaloch/ASPNETIdentityWithOnion)作为我的应用程序架构,在这个示例中,核心是从包括身份框架在内的基础设施中完全取消的.

在此示例中,作者使用适配器模式来分离核心标识类(IdentityUser,IdentityRole ...),并在Core层中提供类似它们的类.

现在这个示例项目中的问题是Domain模型(Product,Images)没有与模仿Identity模型的虚拟类(AppUser,ApplicationRole,AppliationUserRoles,...)链接.

然后我修改了代码以添加对AppUser的引用

public sealed class Image : BaseEntity
{
    public Image()
    {
        Products = new HashSet<Product>();
    }

    public string Path { get; set; }

    public AppUser AppUser { get; set; } // The  Added Reference ...

    public ICollection<Product> Products { get; set; }
}

如果我将"AppUser"导航属性放在"Image"类中,则创建的数据库将具有除标识框架的默认FIVE表之外的四个新表.

我需要将这些表合并为默认表.怎么样 ？

编辑:

这是驻留在数据层中的身份模型(我无法从核心引用).

public class ApplicationIdentityUser :
    IdentityUser<int, ApplicationIdentityUserLogin, ApplicationIdentityUserRole, ApplicationIdentityUserClaim>, IDomainUser {

    public ApplicationIdentityUser()
        : base() {
        Images = new HashSet<Image>();
    }

    public string Name { get; set; …

我正在使用洋葱架构和域驱动设计开发控制台应用程序.我有两个域,我需要实现日志记录,我很困惑我可以放置日志记录组件.我可以将它放在两个域的相应基础架构中吗？或者在共享内核中可以在两个域中引用？如果我需要将它放在共享内核中我应该遵循的结构是什么？我的意思是核心,基础设施.