タグ付けされた質問 「project-structure」

3
タイプ別または機能別フォルダー
AngularJSスタイルガイドを使用します。このガイド内にはfolder-by-feature、の代わりにと呼ばれるスタイルがあり、folder-by-type実際には最良のアプローチは何ですか(この例ではJavaの場合) サービス、コントローラー、リポジトリー、もちろんドメインオブジェクトを使用して、ユーザーとペットを取得できるアプリケーションがあるとします。 folder-by -.....スタイルを使用すると、パッケージ構造に2つのオプションがあります。 1.タイプごとのフォルダー com.example ├── domain │ ├── User.java │ └── Pet.java ├── controllers │ ├── UserController.java │ └── PetController.java ├── repositories │ ├── UserRepository.java │ └── PetRepository.java ├── services │ ├── UserService.java │ └── PetService.java │ // and everything else in the project └── MyApplication.java 2.機能ごとのフォルダー com.example …


3
同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか?
私はモバイルアプリケーションを持つMVCのプロジェクトに取り組んでいるので、モバイルアプリケーションで使用できるようにWeb APIを使用する必要があることは明らかです。 Webサイトの開発を開始したときにAPIを作成した後、私たちは混乱し、APIを使用するか、ビジネスオブジェクトに直接アクセスするかについて議論しました。そして、ビジネスオブジェクトを直接使用する代わりに、Web APIを使用する経験豊富な開発者の意見を聞いた後、私たちは終わりました。 このソリューション構造に関して混乱が生じています。 1)Web APIを使用し、HTTP要求(時間のかかる)を行って、同じソリューションにあるビジネスオブジェクトの代わりにデータを直接取得または配置する必要がある理由。 2)引数を取得した後、クライアントが別のクラウドサーバーでAPIとWebをホストし、APIのみにスケーリングを適用する場合、またはAPIとWebにアクセスするために別のURLを使用する場合(論理的)その場合、同じソリューションでMVCアプリケーションからWeb APIを呼び出す必要がありますか? 3)APIとWebを異なるホスティングでホストしている場合、WebはWebClientを使用し、各ナビゲーションでHTTP呼び出しを行います。正しいですか? 4)別のサーバーでAPIとWebホスティングの両方からビジネスオブジェクトを作成する場合、BLで何か変更を加えた場合は、両方のサーバーでビルドを更新する必要があります。 5)または、API用のプロジェクトを1つだけ作成し、ビューまたはhtmlページを追加してWebインターフェースを開発することで、ajaxから直接APIを呼び出すことができます。 私の知る限りでは、#5が最適なソリューションであるか、APIはサードパーティアクセス専用です。同じソリューションにDB、EF、データ層、ビジネス層がある場合、APIを使用してHTTP呼び出しを行ったり、ビジネスオブジェクトに直接アクセスしたりしないでください。(間違っている場合は修正してください)APIは、モバイルアプリケーションやデスクトップ、またはアプリケーションにアクセスしたいときに同じリポジトリとデータレイヤーを持つために必要です。 私のシナリオでは、モバイルアプリケーションもあるため、APIを作成する必要があります。プロジェクトAPI側では、ビジネスレイヤー(別のプロジェクト)と呼ばれ、ビジネスレイヤーはデータアクセスレイヤー(別のプロジェクト)と通信します。したがって、私の質問は、APIとWebを異なるサーバーにホストする場合、プロジェクトを作成してビジネスレイヤーの.dllを作成するときに、ビジネスレイヤーのメソッドを使用するよりも、HTTPリクエストであるAPIの呼び出しに時間がかかる場合があります APIコントローラーでは、ビジネスの出力をJSON形式に変換するだけです。 インターネットで検索しましたが、納得のいく答えが得られませんでした。私はブログ見つけたhttp://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspxを同じポイントを議論したが、再びそのブログで私の質問は、シナリオ#3を検討する必要がある理由です。 更新:異なるAPIプロジェクトとMVCプロジェクトを使用でき、jvascriptを使用してWebからAPIを呼び出すか、MVVMパターンを使用できます。


5
winformでプロジェクトを適切に構成する方法は?
少し前にwinformアプリケーションの作成を開始しましたが、その時点ではそれは小さく、プロジェクトの構成方法については何も考えていませんでした。 それ以来、必要に応じて追加の機能を追加し、プロジェクトフォルダーはどんどん大きくなっています。今では、何らかの方法でプロジェクトを構成する時が来たと思いますが、適切な方法はわからないので、質問はほとんどありません。 プロジェクトフォルダを適切に再構築する方法は? 現時点では、次のようなことを考えています。 フォーム用のフォルダーを作成する ユーティリティクラスのフォルダーを作成する データのみを含むクラスのフォルダーを作成する クラスを追加するときの命名規則は何ですか? クラスの名前を見るだけで機能を識別できるように、クラスの名前も変更する必要がありますか?たとえば、すべてのフォームクラスの名前を変更して、名前がFormで終わるようにします。または、それらのための特別なフォルダが作成されている場合、これは不要ですか? メインフォームのすべてのコードがForm1.csに収まらないようにするため 私が遭遇した別の問題は、追加する各機能でメインフォームがより大きくなっているため、コードファイル(Form1.cs)が非常に大きくなっていることです。たとえば、TabControlがあり、各タブには多数のコントロールがあり、すべてのコードはForm1.csになりました。これを避ける方法は? また、これらの問題を扱っている記事や本を知っていますか?

5
ユニットテストを整理する最良の方法は何ですか
私たちは、長年にわたってメインプログラムのためにかなりの数の単体テストを構築してきました。数千。問題は、非常に多くのテストがあるため、どのテストがあるのか​​明確に把握していないことです。そして、それは問題です。なぜなら、どこでテストが苦手なのか(または重複箇所があるのか​​)わからないからです。 私たちのアプリはレポートエンジンです。したがって、解析のテスト(すべてのテーブルプロパティを読み取るか)、データのマージ(マージで正しいテーブルプロパティを維持したかどうか)、最終ページのフォーマット(ページがテーブルに正しく配置されているか)に使用するテンプレートを使用できます)および/または出力形式(作成されたDOCXファイルは正しいですか)。 これにテストする必要があるものを追加します。テーブルセルの周りの余白を取ります(レポートデザインにはWord、Excel、およびPowerPointを使用します)。セル内のテーブル、垂直方向に結合したセル、水平方向に結合したセル、内部テーブルに垂直方向と水平方向に結合したセルを含むテーブルを含む垂直方向と水平方向に結合したセルについて、改ページ全体のパディングをテストする必要がありますページを分割します。 それでは、そのテストはどのカテゴリに属しますか?テーブルのパディング、改ページ、ネストされたセル、垂直に結合されたセル、水平に結合されたセル、または他の何か? そして、これらのカテゴリをどのように文書化し、単体テストに名前を付けるなどしますか? 更新:多くの人が、カバレッジツールを使用して、完全にカバレッジがあることを確認することを提案しています。残念なことに、バグは特定の組み合わせに起因する傾向があるため、このケースでは使用が制限されています。そのため、すべてのコードはテスト済みですが、その組み合わせではありません。 たとえば、昨日、テンプレート(Word文書)のforEachループの終わりにWordブックマークを開始し、次のforEachループの始めに終了した顧客がいました。これはすべて単体テストのあるコードを使用していましたが、ブックマークを展開するテンプレートの組み合わせが25回開始され、10回終了することを考えていませんでした(2つのforEachループの行数が異なりました)。

3
MVVM、DDD、およびWPF階層化アプリケーションプロジェクトの構造ガイダンス
私はVSでアプリケーションの構造を設定しようとしていますが、合理的なレベルに「試して」将来的に証明したいと思います。このアプリケーションは、慣例に従わなかった古いWinformアプリをWPFで書き直したものです。レイヤー、ティア、頭字語などはありません... これはかなり大規模なエンタープライズアプリケーションです。私のDBがそうであるように、Linq To SQLを使用する予定であり、ほとんどの場合、常にMS SQLになります。また、既存のスキルセットがあります。 できる限りMVVMとDDDをフォローしたいのですが、これらを組み合わせるとアプリケーションの構造が混乱します。いくつかの例を使って説明してみましょう。 MVVMに従うと、フォルダー構造は次のようになります。 Views Models ViewModels Helpers しかし、私のプロジェクト構造がこれに似ているかもしれない単純化されたDDD階層化アプローチにどのように適合しますか: MyApp.UI MyApp.Domain MyApp.Data Modelsドメインレイヤーに配置するのPersonですか、それともsayの3つのバージョンがありますか?これは、リポジトリとDBオブジェクトのドメインオブジェクトへのマッピングをどこに配置するかという別の質問につながりますか?私はデータを仮定します... Views私はUIに行くだろうが、ViewModelsまただろうか? 最後に、ビジネスロジックをどこに埋め込むか。 CodePlex、DDD Exampleで以下を見つけましたが、いくらか助けになりましたが、Webアプリのように思えますが、それは問題ではなく、私の無知が輝いています。 誤解しないでください。フォルダをいくつでも持つことができ、好きな名前を付けることができます。私は、これらの場所が必ずしも呼ばれているものではなく、これがスケーラブルになるように、物を置く場所を見つけようとしています。 私の質問の核心はこのように示されるかもしれません。によって生成されたオブジェクト がありtblPersonます*.dbml。これは明らかであり、「データ」レイヤーに属します。 これで、Model、DTO、Domain Model、またはと呼ばれる別のLayer(project?)で呼び出されるものがありPersonます。私はどこに置くべきかわからないことのMapperためPersonに必要になるでしょうtblPerson。 次に、ViewModelをEditPerson取得しPersonます。たとえば、それから取得する独自のプロパティがありますが、それ以上の場合もあります。 最後に、そのViewModelにバインドされたビューがあります。 その段落が私の仮定と推測で満たされていることを明確にするために、誰かが私のために空気をきれいにするのを手伝うか、そこから洞察を提供してくれることを望んでいます。

2
HaskellのGUIライブラリに関する提案[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 5年前に閉鎖されました。 以下のようハスケルウィキ自身が述べています: Haskellには多くのGUIライブラリがあります。残念ながら、標準的なものはなく、すべてが多かれ少なかれ不完全です。一般に、低レベルのベニヤは順調ですが、低レベルです。高レベルの抽象化は非常に実験的です。サポートされている中レベルのGUIライブラリが必要です。 私の大学の教授は、私と他の3つのコンピューターサイエンス専攻にHaskellのGUIライブラリを検討するように依頼しました。このプロジェクトに対する彼の最初のアイデアは、Smalltalkにあるモーフィックライブラリを模倣したOpenGLの上にレイヤーを書くことでした。ただし、これは単なる提案であり、他のシステムは間違いなく検討する価値があります。 これは、実際の複数の部分からなる質問につながります。 ライブラリはどのレベルの抽象化のために努力すべきですか?Haskell Wikiは、中レベルのGUIライブラリが推奨されることを強く示しているようです。ただし、高レベルのライブラリは引き続き歓迎されます。 ライブラリを何に構築する必要がありますか?(例:OpenGL) 私たちのライブラリーを模倣したい既存のGUIライブラリー(もしあれば)とその理由は何ですか?(例:PyGame、Morphic、Swingなど) ライブラリの実装または回避を希望する機能は何ですか?たとえば、Gnomeの良き人々は、最小化ボタンは不要だと主張するかもしれません。 一般的な提案はありますか? この架空の図書館にどんな名前を付けますか?(例:HOT-Haskell Opengl Toolkit; HAWT-Haskell Advanced Windowing Toolkit)

6
Business Logic Layer(BLL)はどのような用途に使用されますか?
データベースアプリケーションのグッドプラクティスを読んで、いわゆる「ビジネスロジックレイヤー」の支持者に頻繁に出くわし、自分のプロジェクトがそれを使用するのが最適かどうかを判断しようとしています(小さな個人プロジェクトです)。私の問題は、BLLがDALで処理できないこと(クエリの実行と結果のオブジェクトへのマッピング)を何も考えられないという事実にあるため、BLLは何もせずにDALを呼び出します。 たぶん、DALが何をすべきかについて、私は間違っているかもしれません。しかし、データベース管理アプリケーションのBLLにはどのような機能が期待されるのでしょうか?

5
アーキテクチャ(構造)指向と機能指向のプロジェクト構造
私が関与したプロジェクトには、アーキテクチャ指向のプロジェクトのファイル/フォルダー構造があります。 Root |____ Node1 |____ Event Handlers | |___ <all event handlers of project> |____ Events | |___ <all events of project> |____ Request Handlers | |___ <all request handlers of project> |____ Requests | |___ <all requests of project> |____ ... システムのアーキテクチャの観点から明らかです(開発チームによって提案されています)。 デザイナーチームによって提案された機能指向の構造です。 Root |____ Feature #1 |____ Event …

4
命名の競合を回避するCプロジェクト
中規模のCライブラリプロジェクトの関数命名規則に関する実用的なアドバイスを見つけるのに苦労しています。私のライブラリプロジェクトは、独自のヘッダーを持ついくつかのモジュールとサブモジュールに分割され、大まかにOOスタイルに従います(すべての関数は、グローバルなどではなく、最初の引数として特定の構造体を取ります)。次のように配置します。 MyLib - Foo - foo.h - foo_internal.h - some_foo_action.c - another_foo_action.c - Baz - baz.h - some_baz_action.c - Bar - bar.h - bar_internal.h - some_bar_action.c 一般的に、関数は大きすぎて(たとえば)固執some_foo_actionしanother_foo_action、1つのfoo.c実装ファイルに入れて、ほとんどの関数を静的にして、1日で呼び出します。 ユーザーのクライアントプログラムとの競合を避けるために、ライブラリを構築するときに内部(「モジュールプライベート」)シンボルを削除することもできますが、問題はライブラリ内のシンボルの名前の付け方ですか?これまで私はやってきた: struct MyLibFoo; void MyLibFooSomeAction(MyLibFoo *foo, ...); struct MyLibBar; void MyLibBarAnAction(MyLibBar *bar, ...); // Submodule struct MyLibFooBaz; void MyLibFooBazAnotherAction(MyLibFooBaz *baz, ...); しかし、私は(例よりはるかに長い)クレイジーな長いシンボル名になってしまいました。名前の前に「偽の名前空間」を付けない場合、モジュールの内部シンボル名はすべて衝突します。 注:キャメルケース/パスカルのケースなどは気にせず、名前だけを気にします。

6
大規模なJavaScriptアプリケーションの構造はどのようになっていますか?
最近、OBIEE Mobile App Developer用に記述されたJavaScriptプラグインと、さまざまなプロジェクト用のカスタムライブラリを紹介しました。 OOPのバックグラウンドから来て、私はこれらのプロジェクトの構造について少し混乱しています。何千行ものファイルが表示されています。私は物事をファイルとクラスに分割することに慣れていますが、これは別のフレームワークであることを理解しています-たとえば、ファイルサイズが問題です-しかし、それをすべて行うより良い方法が必要ですか? スクリプトの長さは、読みやすさと保守性だけでなく、プログラムの動作に関する個人の一般的な理解にも影響します。 大規模なアプリケーションはどのように構成されていますか?このための一般的なOOP設計パターンはありますか?

2
Javaプロジェクトの分離
大規模なJavaプロジェクトがあり、ビルドサイクルにmavenを使用しています。この1つのプロジェクトは広く使用されています-他のプロジェクト、さまざまなアプリケーション、その中に含まれているものと他の場所にあるもの...正直に言うと、それはちょっとした混乱です目的)、そして私はそれを少しきれいにしたいと思います。また、完全にはテストされていません(適切なユニットおよび統合テストなしで多くのビットが追加されています)。実行に時間がかかるか、実際に合格しないテストがいくつかあります...(uh-oh)-そうテストはMavenビルドサイクルでオフに切り替えられます(繰り返しますが)。 「最終」サブプロジェクト(または複数のサブプロジェクト)が必要とするさまざまなサブプロジェクトを選択できるように、この大きなプロジェクトを小さな特定のプロジェクトに分割することを考えています。 私の考えは次のとおりです。 大きなプロジェクトをさまざまなサブプロジェクトに分けると、各プロジェクトの責任が明確になります。 サブプロジェクトに分けることで、各サブプロジェクトのテストを個別にクリーンアップし、Mavenビルドサイクルでそのサブプロジェクトのテストを有効にできます。 これがビルド時間に与える影響について少し懸念しています。 大きなプロジェクトに構造を課す(つまり、小さなサブプロジェクトに入れる)と、コンパイラの速度が低下しますか? また、IDEでの編集時間にどのような影響があるかも少し懸念しています(主にIntellijを使用しています)。Intellijは依存関係ツリーを介して各プロジェクトを順番にビルドするようです。つまり、CがBに依存し、Aに依存し、Aを変更すると、Aがコンパイルしない限りBをビルドしようとしません。おそらくそれは有利ですが、たとえば、BおよびCで広く使用されているAのインターフェイスを変更すると、その変更によるすべてのエラーを修正するのに時間がかかることがわかりました... もう1つの質問は、ファクトリクラスの使用方法です。プロジェクトの一部の側面は外部jarに依存しています。時折(ありがたいことに頻繁に)これらは更新され、移行する必要があります。外部コードの正しいバージョンを指すFactoryクラスを使用してこれを処理する傾向があります(したがって、コードベース全体のすべての実装を変更する必要はありません)。 現時点ではこれはすべて大規模なプロジェクトですが、サブプロジェクトに切り替えることで、新しい外部コードを実装するための新しいプロジェクトを開発し、サブプロジェクトが完全に機能し、テストされていることを確認できます。次に、ユーザープロジェクトの依存関係/ファクトリクラスを切り替えます。ただし、大規模なプロジェクト全体でインターフェイスを広範囲に使用するため、これはより複雑になります。例えば サブプロジェクトA-インターフェースを含む サブプロジェクトB-インターフェースと古い外部jarはAに依存 サブプロジェクトC-B(およびAおよび古い外部jar)に依存し、Bのインターフェース実装を使用するFactoryクラスを含む Bの外部jarを変更する必要がある場合、次のことができます。 サブプロジェクトB_iiの作成-再びAに依存し、新しい外部jar 完全に機能したら、Cの依存関係をB_iiに追加し、インターフェイスの新しい実装を使用するようにFactoryクラスを変更できます。 すべてが機能したら、Cの元のBへの依存関係を削除し、必要に応じてサブプロジェクトBを削除できます。 これは賢明な方法ですか? だから、一般的に、私の質問は次のとおりです。 大規模なプロジェクトを解体した経験はありますか?共有したいと思うヒント/トリックはありますか? これは開発およびビルド時間にどのような影響を与えましたか? このようなプロジェクトのこのような分裂を構造化する上で、どのようなアドバイスを提供できますか?

1
iOSアプリ開発用のコードの整理
私はiOSプラットフォーム用のアプリを開発してきましたが、これまでずっと、ファイル(.h、.m、.mm)を整理するというひどい仕事をしてきたことに気づきました。iOSプロジェクトのファイルの整理に関して、業界標準やベストプラクティスはありますか? 私のファイルには、カスタムクラス(View Controllerの横)、カスタマイズされたView Controller、サードパーティのコンテンツ、iOS 5.0以降でのみ動作するコード、以前のバージョンで動作するコードが含まれています。私が探しているのは、他の人(または今後数年のうちに私)がこれを見て、そこにある複数のファイルで迷子にならないように、物事を整理するソリューションです。

4
個人の使い捨てプロジェクトをホストする場合、1つのサービスとプロジェクト構造が際立っていますか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は、Google Code、SourceForge、BitBucket、およびGitHubを見ています。彼らは大きなプレーヤーのようです。今、私はまだそれらが提供するすべての機能を分解していませんが、私が書くさまざまなコードを置く場所を本当に探しています(プロジェクトオイラーの私のソリューション、コードゴルフ/プログラミングパズルスタック交換など)を中央の場所で行います。 それで、私の最初の質問はこうです:このような状況では、あるサービスが他のサービスの中で際立っているのでしょうか? サービスを選択したら、コードの配布方法を選択する必要があります。リポジトリとプロジェクトを設定するためのオプションがいくつかあります。単一のリポジトリに任意の数のプロジェクトを保持できます。たとえば、Project Eulerのさまざまなソリューションすべてに対して、「Tom OwensのProject Euler Solutions」リポジトリを作成できます。私のさまざまなCode Kataソリューションなどに。または、そのようなものを言語ごとに分類することもできます(あるリポジトリのPythonのProject Eulerソリューション、別のリポジトリのJavaのPEソリューション、および3番目のリポジトリのCode Kata C ++ソリューションを使用)。 2番目の質問:特にリポジトリの作成方法に関して、オープンにすることを選択したコードサンプルを共有する方法を決定するための制限または規則はありますか?私の考えでは、これはあなたが選択したサービスによって決定されるかもしれない(コミュニティの慣習に基づいて)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.