Question

我正在研究面向服务的体系结构。我有3个表Meeting，Stakeholder和MeetingStakeholder（联结表）。

所有3个表的POCO类的简单表示形式：

public class Meeting
{
    public int Id { get; set; }
    public IList<MeetingStakeholder> MeetingStakeholders { get; set; }
}

public class Stakeholder
{
    public int Id { get; set; }
}

public class MeetingStakeholder
{
    public int Id { get; set; }

    public int MeetingId { get; set; }
    public Meeting Meeting { get; set; }

    public int StakeholderId { get; set; }
    public Stakeholder Stakeholder { get; set; }
}

会议Dto的简单表示形式：

public class MeetingDto
{
    public int Id { get; set; }
    public IList<int> StakeholderIds { get; set; }
}

在PUT操作中，

PUT: api/meetings/1

首先，我从MeetingStakeholder（连接表）中删除所有现有记录，然后使用List<MeetingStakeholder> meetingStakeholders准备新的meetingDto.StakeholderIds并创建它。

{
   List<MeetingStakeholder> existingMeetingStakeholders = _unitOfWork.MeetingStakeholderRepository.Where(x=> x.MeetingId == meetingDto.Id);
   _unitOfWork.MeetingStakeholderRepository.RemoveRange(existingMeetingStakeholders);

   List<MeetingStakeholder> meetingStakeholders = ... ;

   _unitOfWork.MeetingRepository.Update(meeting);       
   _unitOfWork.MeetingStakeholderRepository.CreateRange(meetingStakeholders);
   _unitOfWork.SaveChanges();

   return OK(meetingDto);
}

一切对我都很好。但是我的建筑师告诉我，我做错了事。他说，在PUT行动中（根据SRP），我不应该删除并重新创建MeetingStakeholder记录，我应该只负责更新会议对象。

据他说，MeetingStakeholderIds（整数数组）应在请求正文中发送到这些路由。

用于分配新的利益相关者参加会议。

POST:  api/meetings/1/stakeholders

用于从会议中删除现有的利益相关者。

Delete: api/meetings/1/stakeholders

但是问题是，在会议编辑屏幕中，我的前端开发人员对利益相关者使用多选。他将需要维护两个整数数组。

那些最终用户从多选中取消选择的利益相关者ID的第一个数组。新近选定的利益相关者ID的第二个数组。然后，他会将这两个数组发送到各自的路由，如上所述。

如果我的建筑师是正确的，那么我没问题，但是我的前端开发人员应如何在编辑屏幕中处理涉众选择？

我要澄清的一件事：我的联结表非常简单，除了MeetingId和StakeholderId（一个非常基本的联结）之外，它不包含其他列。因此，在这种情况下，在接收StakeholderIds （整数列表）的“ api / meetings / 1 / stakeholders”上创建单独的POST / DELETE操作有意义吗，而不是直接在MeetingDto中接收StakeholderId？

Answer 1

首先，如果我没记错的话：

您有一个资源：“会议”；
您要（使用HTTP / PUT）更新所述资源。

因此，通过在“ / api / meetings /：id”上请求PUT来更新会议似乎非常简单，简洁，直接且清晰。设计良好界面的所有良好特征。而且它仍然尊重“单一责任原则”：您正在更新资源”

尽管如此，我也同意您的架构师的意见，如果有必要的话，除了提供以前的方法外，还应针对“ api / meetings / 1 / stakeholders”提供POST / Delete操作。我们应该在某种程度上务实，不要过度设计不必要的东西。

现在，如果您的架构师只是说，由于坚持不懈，那他是错的。最终用户（现在的前端，明天的另一项服务或应用程序……）对接口应该是清楚的，但是最重要的是，在这种情况下，它不知道接口的持久性或与此相关的任何实现。

您的api应该专注于您的域和业务规则，而不是您如何存储信息。

这只是我的看法。如果有人不同意我的意思，我希望被人叫走，这样他们可以一起成长和学习。

:)希望我能有所帮助。干杯

REST API处理结点数据的最佳实践

1 个答案: