OOP 基础 - C# 重构？答案

【问题标题】：OOP Fundamental - C# Refactoring?OOP 基础 - C# 重构？
【发布时间】：2017-02-27 05:35:29
【问题描述】：

（对不起，如果标题不合适，不知道如何正确表达问题）

一个User（一个人）拥有一个Property（一所房子，带有街道地址等）。

我正在重构一个项目，遇到以下情况。我有一个名为Property 的类和一个名为User 的类。

业务规则：用户拥有一个或多个属性。

那么，更有意义的是：

User.GetProperties()或

Properties.Get(userId)

目前我正在通过User 类访问属性。不确定这是否是处理这种关系的常用方法。你们怎么看？

我在这里向前思考，担心的原因是因为我以后会有：

Property.Get(state)

Property.Get(zip)

Property.Get(city)

Property.Get(numberOfBedroom)

等等……

其他获取属性的方法，我知道这些可以通过Property 类访问。正确的？（我对此很坚定）所以考虑到这一点，这是否会改变访问用户属性的方式？

更新

我不是在问如何正确创建类，就像我说的我有两个类。我的问题，更好的说法是：

如果我的 web api，对于给定的场景（User 有一个或多个 Property[ies]）：

/api/user/properties/{userId} // get all user properties

或

api/property/user/{userId} // get all user properties

因为我明确会实施：

api/property/zip/{zipCode} // get all properties by zip

api/property/state/{state} // get all properties by state

api/property/city/{city} // get all properties by city

等

那么，鉴于最后 3 个例子，你会

(a) 实现/api/user/properties/{userId}，同时为后面的 3 种情况实现所有api/property/...

或

(b) 保持一致并从api/property/user/... 角度查询User 的Property[ies]？

那么，在回答完这个问题之后，我仍然可以使用带有GetProperties() 方法的User 类，该方法返回List<Property>

或

我可以让Property 类带有一个返回List<Property> 的GetByUser(int userId) 方法

因为在现实世界中，User 有 1 个或多个 Property，而不是相反。所以我们基本的 OOP 直觉是这样建模，但是在考虑 WebApi 和可能公开暴露的 API 时，我认为后者是首选，但从 C#（我的服务器端）从 @987654354 获取 Properties @ 是有意义的，但我的前端开发人员（jQuery、Angular、JavaScript 等）想要流畅的 API，api/property/user/... 可能是合乎逻辑的，我可能不会考虑查看 api/user/propties/...（或我可能）...

那么，您将使用哪种 API 方法以及为什么，以及您将使用哪种类模型以及为什么。

谢谢。

更新 2

（自言自语）“答案可能是两者”两种方式创建 api api/user/properties/... 用于 OOP 正确性和 api/property/user/... 用于流利的 api，并且两者都调用相同的 Class 方法？对吧？

【问题讨论】：

您的业务规则似乎更复杂：有一个属性描述符列表，用户可以为这些描述符拥有一个或多个属性值。是真的吗？
即兴猜测 - 您对跟踪/识别属性比对跟踪/识别用户更感兴趣。在我看来，您的 API 应该是关于属性，以及获取您关心的属性集合的各种方法，而不是关于用户、ZIP 或状态。简而言之，我认为 api/properties/[some attribute of property/{[attribute value]} 会形成一种相对干净、易于理解的格式。
已更新，没有“用户（个人）拥有财产（房屋、街道地址等）。”
我已经删除了我的答案，显然我很失望......你不能用非常笼统的文字提出问题，让人们努力解决你的问题和 10 小时稍后更改文本，使其与原始问题无关：现在与 REST 和其他问题相关..........
@MatíasFidemraizer 是我的错，我误报了这个问题，对于给您带来的不便，我们深表歉意。但是感谢您的专业意见！ :-)

标签： c# class oop hierarchy

【解决方案1】：

您正在混合 2 个不同的东西：您的实体（人员、财产）和您的业务逻辑。在我看来，您应该有 Person 和 Property 类，并且 Person 类将有一个 Properties 集合，但业务逻辑应该转到一个单独的组件，即 PropertyComponent（或只是 PropertyRepo），它将具有 GetPropertiesByState、GetPropertiesByUser 方法等等

【讨论】：

【解决方案2】：

Rest 应该使用资源标识符来识别资源。在我看来，api结构应该是

/api/users/ --> Get all users
/api/users/{userId} --> Ger one user
/api/users/{userId}/properties/ --> Get properties of one user
/api/users/{userId}/properties/{propertyid} --> Get one property of one user

获取属性

/api/properties/ --> Get all properties
/api/properties/{propertyid} --> Get one properties
/api/properties?filter=(zip:zipCodeValue) --> Get all properties by zip code
/api/properties?filter=(state:stateValue) --> Get all properties by state

休息有用的参考https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

【讨论】：