2017-12-13 9 views
1

다음 항목을 먼저 EF 코드를 사용하여 Microsoft SQL Server 데이터베이스에 유지되고 개발 될 것이다 : 다음과 같이 의미 중첩 된 클래스를 정의하는 것이 항상 더 나은클래스 디자인에서 중첩 클래스가 항상 더 좋습니까?

enter image description here

입니다 (약식 정의는 간단하게하기

Public Class Assembly 
    Public Property assemblyID As Integer 
    Public Property parts As New List(Of Part) 
End Class 

Public Class Part 
    Public Property partID As Integer 
    Public Property subitems As New List(Of Subitem) 
End Class 

Public Class Subitem 
    Public Property subitemID As Integer 
    Public Property components As New List(Of Component) 
End Class 

Public Class Component 
    Public Property componentID As Integer 
    Public Property elements As New List(Of Element) 
End Class 

Public Class Element 
    Public Property elementID As Integer 
    Public Property Name As New List(Of String) 
End Class 

을 또는 이제까지 아래 의미 별도의 클래스를 유지하고 각 클래스의 레코드 사이의 관계를 유지하는 수동 작업을 할 어떠한 이유가있다 :), 데이터베이스를시키는 것은 관계를 유지하는 일을 :

Public Class Assembly 
    Public Property assemblyID As Integer 
    Public Property parts As New List(Of Integer) 'which would be partIDs 
End Class 

Public Class Part 
    Public Property partID As Integer 
    Public Property subitems As New List(Of Integer) 'which would be subitemIDs 
End Class 

Public Class Subitem 
    Public Property subitemID As Integer 
    Public Property components As New List(Of Integer) 'which would be componentIDs 
End Class 

Public Class Component 
    Public Property componentID As Integer 
    Public Property elements As New List(Of Integer) 'which would be elementIDs 
End Class 

Public Class Element 
    Public Property elementID As Integer 
    Public Property Name As New List(Of String) 
End Class 

저는 실제 데이터의 구조를 따르기 위해 중첩 된 클래스를 설계해야한다고 항상 생각했습니다. 그러나 이것은 더 깊숙한 중첩이기 때문에 고려해야 할 다른 설계 방법이있는 경우에 대비하여 요청할 것이라고 생각했습니다.

이 특별한 경우 모든 레코드는 고유합니다. I.E. 조립 된 부품처럼이 모양을 만들었지 만, 각 레벨의 이름을 뚜렷하게 지정하려고했습니다. 그러나이 경우이 레이어 항목 중 하나는 다른 어셈블리에서 사용되지 않습니다.

+0

(아마도) 고려해야 할 것이 있습니다. 자녀 콜렉션에는 ~~ 관계 ~~에 대한 속성이 있습니까? 예를 들어. 직원은 많은 JobTitles를 가질 수 있습니다. 그러나 EmployeeStartedJobTitleOn (날짜) 속성은 Employee의 속성이 아니며 JobTitle의 속성이 아닙니다 (다른 직원이 다른 날짜로 시작할 수 있음) ..... ~ ~ 관계의 속성 (직원이 ~ 이 특정 날짜의 JobTitle). 이 경우 EF 일부를 다시 작성해야합니다. StartDate를 정의하는 EmployeeToJobTitle 객체가 있어야합니다. – granadaCoder

+0

내가이 문제를 제기하는 이유는이 "전술"또한 EF Poco 's를 정의하는보다 복합적인 방법에 대한 방법이기 때문입니다. "Element"가 (그림과 같이) Component의 하위 컬렉션 일 수는 있지만 뭔가 (예 : 표시되거나 추측 된) 부품의 하위 컬렉션 인 경우 ... "링크"개체를 사용하여 관계. #foodForThought하지만 동시에 구석에 그림을 그려서는 안됩니다. 엔티티가 "재사용"될 수도 있다고 생각하거나 ~ ~ 관계에 대한 속성 일 수도 있다고 생각한다면, 나는이 중간 남자 오브젝트를 미래의 자신을 위해 설정할 수 있습니다. – granadaCoder

답변

1

모든 구조물의 깊이가 같으면 모델이 가장 좋을 수 있습니다. 그렇지 않으면 계층 구조를 고려하십시오. 이 같은.

Public Class PartModel 
    Public Property Id as Integer 
    Public Property Name As String 
    Public Property ParentId As Integer? ''Nullable(Of Integer) 
    <ForeignKey("ParentId")> 
    Public Property SubParts As List(Of PartModel) ''Note no **New** here. New will be in a Controller 
End Class 
+1

계층 구조를 사용하지 않는 것이 적절한 지 확인하기위한 Thx입니다. 그리고 그것을하는 적당한 방법을 보여주기를위한 thx. 위의 두 번째 예제는 분명히 올바른 방법이 아니지만 내 의도가 있고 여기에서 수정했습니다. 나중에 계층/레벨 정의가 갈라질 수 있다는 것이 분명 해졌 기 때문에 결국 위의 첫 번째 예제를 사용하기로 결정했습니다. – Alan