프로젝트 구조의 일부인데요… (생각같아선 다 올리고 싶은데 캡쳐가 힘드네요)
일단 UseCase나 Core부분은 별도의 프로젝트에 있고,
그 외 프론트를 책임지는 프로젝트의 구조입니다…
상태가 꽤나 심각해보이지요? 실컷 코딩에만 몰입하다가 펼쳐본 프로젝트 구조가 아주 가관이라서…
모든 종류의 질책과 조언을 좀 받고싶습니다…
Blazor Server 이고요. 뭐 웹이건 윈도우건 자기 전문분야를 떠나서 파일 네이밍이든 뭐든 어떤 종류든 조언을 구하고 싶습니다.
씨게 때려주세요…
1개의 좋아요
글쎄요… 프로젝트 구조는 일관성만 유지하면 된다고 생각합니다. 가령,
Pages/
의 페이지가 하위 디렉토리에 배치해야 한다 등은 규모와 취향의 문제 같아요.
보여주신 내용 중 저랑 스타일이 다른 것은 파일명의 Page
위치 정도인데요, Pages/
에는 페이지만 담길 것이므로 저 같은 경우 Page
를 생략하거나 Page
를 파일명의 가장 뒤에 둡니다.
PageTicket → TicketPage
참고로 Blazor의 경우 컴포넌트 단위이 쉽기 때문에 반복해서 사용하는 컴포넌트는 별도로 잘 구성해 놓으면 편리합니다. 공유된 프로젝트 구조에서는 아마도 Controls
일 듯 보이는군요. ^^
3개의 좋아요
rkttu
6월 16, 2023, 8:40오전
3
채찍질이요? (동공 지진)
다만 한 가지 고려해보심직 한 것은, Razor 프로젝트도 요즈음은 Razor 뷰를 유지한채로 분리된 프로젝트를 만드는 옵션을 쓸 수 있을 것으로 알고 있습니다. 해서, 한 프로젝트에 너무 많은 코드가 몰려있는 것이 유지보수에 영향을 준다고 생각하시면, 프로젝트 단위로 코드를 분리해보는 것 정도를 PoC 해보시면 어떨까 제안드립니다.
그 외에도, 비즈니스 로직의 깊이가 깊어져서 뷰가 여러개가 만들어질 것으로 예상이 된다면, 폴더 구조를 좀 더 세분화해서 서브폴더 (예: Pages/Board 혹은 Pages/Tickets 같이?)를 두는 것도 생각해볼만한 옵션일 수 있을 것 같습니다.
그리고 무엇보다도 프로젝트 규모가 커진다면, 적정한 문서화가 같이 이루어져야 한다고 생각합니다. ㅎㅎ
3개의 좋아요
파란매
6월 16, 2023, 8:47오전
4
3개의 좋아요
페이지 결정은 디자인 디테일에 종속된 것이라, 프로젝트 마다 다를 것입니다.
제 개인적으로는 디자인 디테일에 크게 구애 받지 않는 상황이라, 한 모델에 관한 CRUD를 페이지 별로 구분하는 것은 페이지 파일의 갯수와 라우팅 포인트가 너무 많아지는 느낌이 있어, 가급적 한 곳에 다 때려 박는 스타일입니다.
만약, 보여주신 Page 폴더 중 Contract 객체에 제 스타일을 맹목적으로 적용한다면, 아래와 같이 할 것 같습니다.
페이지: ContractPage (“/contract/{principalId:guid?}”)
콘트롤: InputContract(모달), EntityTable<T> (별도 디자인이 필요한 경우, ContractList)
ContractPage 의 구조는 대략 아래와 같습니다.
@if(_isInputShowing)
{
<InputContract Entity="@_contract".../>
}
<EntityTable Entities="@_contracts" ColumnsCSV="Id, Name, Address1, Address2">
<CreateController> // RenderFragment
<button ... @onclick="@OnCreateClicked">추가</button>
</CreateController>
<Controllers> // RenderFragment<T>
<button ... @onclick="@(() => OnUpdateClicked(context))">수정</button>
...
</Controllers>
</EntityTable>
3개의 좋아요
안그래도 예전 제 글에 달아주셨던 @BigSquare 님의 댓글을 다시 보던 참이었습니다.
DbContext 자체가 unit of work 에 대한 추상 레이어라서, 우리는 이를 구현해서 사용합니다.
ApplicationDbContext : DbContext
만약, 데이터 베이스가 아니라, 파일에 저장하는 경우를 고려하면 IRepository 로 한번 더 추상화할 필요도 있겠지만, 대규모 프로젝트에서 데이터 베이스를 사용하지 않는다는 것은 상상할 수 없는 얘기죠.
자료의 저장소로 데이터 베이스가 언제나 전제된다면, DbContext를 IRepository로 감싸는 것은 추상에 대한 추상일 뿐으로, 불필요한 복잡성에 지나지 않습니다.
따라서, 제가 든 코드의 예에서 IRepository를 사용한 것은, DbContext를 사용하는 환경이라면, 불필요하게 복잡하게 설계한 오류입니다.
다만 인터페이스를 사용하면서 혼란을 느끼신다면, 아래의 글을 참고하시면 좋을 것 같습니다.
윗 글은 인터페이스를 누가 정의해야 하고, 누가 구현해야 하는 지를 설명하고 있습니다.
여…
실용적이면서도 고급스러운 모양새를 갖추고 싶은 욕심이 있다보니 이런 질문을 또 다시 드리게 되네요.
도움을 얻을 길은 여기에 글을 올리는 것 밖에 없고 보답할 방법도 없다는게 아쉽긴 합니다.
올려주신 댓글 보고 더 공부하겠습니다. 감사합니다.
3개의 좋아요
올려주신 BolierPlate가 api형식이긴 해도 참고할 만한 내용들이 있는 것 같습니다.
감사합니다.
그리고 저는 Classic충(?)이라 뭐든 기본테마, 순정을 좋아합니다
1개의 좋아요
채찍질도 여기 계신 후덜덜한 고수님들한테 받는다면 영광이죠…
돈내고 들어야 할 강의 수준인데…ㅎㅎ
뷰를 유지한 채로 프로젝트를 분리한다라…
이렇게 만들어진 예제를 한번 찾아봐야겠네요.
그리고 말씀해주신대로 페이지를 폴더로 구분해서 담긴 했는데, 1~2개 짜리로 끝나는 페이지 분류들이 많아서리 어떻게 하는게 짧고 굵게 보일까 고민중입니다.
조언 감사합니다. 정답은 없겠지만, 똥 된장 다 찍먹해가며 좋은걸 찾아봐야겠습니다.
아, 그리고 문서화는 어떻게 하는걸 말씀하시는 건가요? 각 파일이나 디렉터리에 대한 설명을 말씀하시는건가요?
2개의 좋아요
말씀해주신대로 반영해보았습니다
DTO도 마찬가지로 FooDto.cs 이런식으로 바꿔놓으니 좋네요.
뭐든지 Foo.razor, Foo.cs 이런식으로 되어있다보니 이게 '작동’을 구현해놓은 클래스인지 '정의’를 구현해놓은 클래스인지 구분도 안되고 그랬는데, 이젠 명확하게 보입니다.
3개의 좋아요