1

おそらく適切な用語を持っていないため、タイトルがあまり明確ではないことはわかっていますが、例を挙げれば明確になるはずです。投稿とコメントを含むアプリがあるとします。それらをさまざまな方法の名前空間/パッケージにグループ化する限り、ベスト プラクティスは何でしょうか。良い方法がない場合、両方の長所と短所は何ですか。ここに私が想像したいくつかの異なる方法があります。これは決して網羅的なものではなく、要点を理解するためのものです。

1)

MyAp
|--Entities
|  |--AbstractEntity.class
|  |--Comment.class
|  |--Post.class
|--DataMappers
|  |--AbstractDataMapper.class
|  |--CommentDataMapper.class
|  |--PostDataMapper.class
|--DataMappers
|  |--AbstractService.class
|  |--CommentService.class
|  |--PostService.class

2)

MyAp
|--Abstract
|  |--AbstractDataMapper.class
|  |--AbstractEntity.class
|  |--AbstractService.class
|--Impl
|  |--Comment
|  |  |--Comment.class
|  |  |--CommentDataMapper.class
|  |  |--CommentService.class
|  |--Post
|  |  |--Post.class
|  |  |--PostDataMapper.class
|  |  |--PostService.class

大きなプロジェクトでは、上記の方法のいずれかをより広いグループに分割できます。たとえば、#1 では、Entities、DataMappers、および Services 名前空間の下に Db、Util、System などを配置し、そこにクラス実装を配置して、AbstractEntity クラスを Entities 名前空間の下に保持できます。#2 については、Abstract と Impl の下にこれらの追加の名前空間を配置して同じことを行うことができます。

私は＃1の方が優れていることに傾いています.Db、Util、Systemなどの名前空間を2つの異なる場所に追加する必要があるようです。しかし #2 には、1 つのモデル クラスに関連するすべてのクラスをまとめておくという魅力があります。決められない！

4

3 に答える 3

2

どちらのアプローチにも問題があると思います。

ほとんどの開発者は、主な専門分野によってクラスを分割する傾向があります。マッパーはマッパーに行き、モデルはモデルに行き、ヘルパーはヘルパーに行き、インターフェースはインターフェースに行くべきだと私たちは最初に考えます。これはプロジェクトの開始時に簡単に決定できますが、時間が経つにつれて多少の苦痛を引き起こします。時々かなりばかげているように見えます。特に、特定の機能を別のコンポーネントに抽出する必要がある場合。

私の経験から、クラスを高レベルの関数、「サブシステム」、または現在のDDDで「有界コンテキスト」でグループ化する必要があると言えます。同時に、レベルをグループ化することはあまりないはずです。

つまり、すべてのエンティティが投稿コンテキストに属していることがわかります。奇妙に見えるかもしれませんが、コンテキスト内に非常に特定の機能領域がない限り、すべてのクラスをPostingfodlerに配置し、余分なサブフォルダーを作成しないことをお勧めします。

MyAp
|--Core
   |--AbstractEntity.class 
   |--AbstractDataMapper.class
   |--AbstractService.class
|--Posting
   |--Comment.class
   |--Post.class
   |--CommentDataMapper.class
   |--PostDataMapper.class
   |--CommentService.class
   |--PostService.class

一般に、2番目のアプローチは似ています。その場合、コンテキスト固有のフォルダを簡単に追加できます。-'Voting'、'Notifications'、'Authentication'など。また、最も簡単な方法を選択し、クラスの「クリティカルマス」ができるまで待って、方法に関する十分な情報を入手することをお勧めします。クラスを正しくグループ化します。

最初のアプローチでは、ドメインのコンテキストはすべてのフォルダーに分散されます。

于 2012-12-15T18:23:53.173 に答える
1

私の経験では、後者よりも最初の FAR の方が多く見られました (実際、最初の FAR で分割されたプロジェクトを見たことがないと思います)。

例: ハリウッド パターンを使用する抽象クラスがあるとします。すべての実装クラスは、合理的に同じパッケージに含まれます。実際の実装から遠く離れた「抽象」パッケージで「マスター」テンプレートをオフにすることは意味がありません。

私が追加するもう1つのことは、SINGULAR IN ALL CASES EXCEPT COLLECTIONSです。

MyAp
|--Entity
|  |--AbstractEntity.class
|  |--Comment.class
|  |--Post.class
|--DataMapper
|  |--AbstractDataMapper.class
|  |--CommentDataMapper.class
|  |--PostDataMapper.class
|--Service
|  |--AbstractService.class
|  |--CommentService.class
|  |--PostService.class
于 2012-12-14T16:13:44.323 に答える
0

JaxB などの一部のフレームワークは、構成情報を package-info.java に入れます。その場合、package-info.java を使用するには、最初の方法が必須です。

于 2012-12-18T12:02:42.433 に答える