問題タブ [software-design]

デスクトップソフトウェアデザインの最初の試みに着手しようとしていますが、Webデザインのコア原則の背後にある類似点、相違点、本や記事などを知りたいと思いました。

どんな助けでも大歓迎です。

DTO 型がドメイン モデル内で作成され、型間で受け渡されていることがわかります。これは良い習慣ですか？

私は常に、DTO は主にコンテキスト境界 (オブジェクト グラフの端) で使用され、コンテキスト実装を分離する (ドメイン/UI 境界など) と考えていました。

たとえば、Mark Zuckerberg がインタビューで Facebook を 2 週間で書いたと言ったとき、彼は正確に (または少なくともおおよそ) 何を書いたのでしょうか? 他のユーザー オブジェクトへのリンクをネゴシエートする機能を備えた、大きなデータベースまたはツリー内の "ユーザー" オブジェクトを想像しますが、ツリーの包括的なマネージャーがどのように機能するのか疑問に思っています。ユーザーがログインすると、「メイン」プログラムはそのユーザーのオブジェクトを検索し、ユーザーがログインしている間に他のユーザー オブジェクトと対話するためにプロセスをフォークしますか? ありがとう。

一般に、ソフトウェア設計において、データベースやファイルなどのリソースに問題やエラーが発生した場合、次のどのオプションが優先されますか?

1. エラーメッセージを表示
2. エラー メッセージを表示せず、リソースが空であるかのように動作します (例: GUI コンポーネントを設定しません)]

たとえば、空の DataGrid が表示された後に文句を言うべきか、それともエラー メッセージが表示されるべきか? どちらが良いですか？

この質問を見ました: 「ユーティリティ」クラスが悪い場合、汎用コードをどこに配置すればよいですか?

そして、なぜユーティリティクラスは悪なのでしょうか?

数十クラスの深さのドメイン モデルがあるとします。インスタンスを xml 化できるようにする必要があります。親で toXml メソッドを作成しますか? MyDomainXmlUtility.toXml ヘルパー クラスを作成する必要がありますか? これは、ビジネス ニーズがドメイン モデル全体に​​及ぶ場合です。それは本当にインスタンス メソッドに属しているのでしょうか。アプリケーションの XML 機能に多数の補助メソッドがある場合はどうでしょうか?

私は、主な設計指針の原則が拡張性であるプロジェクトに取り組んでいます。

クラス メソッドを使用して、読み込まれるプラグインのクラス名を登録するメタクラスを定義することにより、プラグイン システムを実装しました(各タイプのプラグインは、コア コードで定義された特定のクラスから継承します。アプリケーション）。基本的にこれは、開発者が自分のクラスを次のように定義する必要があることを意味します。

PieChartで利用可能な登録済みプラグインのリストに含まれるため、メインプログラムは彼の存在を認識しChartPluginAncestor.pluginsます。

マウント メソッドがクラス メソッドであるため、すべてのプラグインは、クラス コードがメモリに読み込まれるときに登録されます (したがって、そのクラスのオブジェクトがインスタンス化される前であっても)。

システムは私にとっては十分に機能します ™ (ただし、アーキテクチャを改善する方法についての提案はいつでも受け付けています!) しかし、プラグイン ファイルを管理する最善の方法は何か (つまり、プラグインを含むファイルの場所と方法) を考えています。保管する必要があります）。

これまでのところ、開発目的で「プラグイン」と呼ばれるパッケージを使用しています。プラグイン クラスを含むすべての *.py ファイルをパッケージ ディレクトリにimport plugins置き、すべてのプラグインが適切にマウントされるように、main.py ファイルで発行するだけです。

編集:ジェフは、パッケージのさまざまなモジュールに含まれるクラスがすぐに利用できないことをコメントで指摘しましたimport plugins(デバッグ目的で、各クラスを個別にインポートしていたため、これに気づきませんでしたfrom plugins.myAI import AI)。

ただし、このシステムは、次のように、コードを開発およびテストしている間のみ有効です。

• プラグインには独自のユニットテストが付属している場合があり、それらをメモリにロードしたくありません。
• すべてのプラグインは現在メモリにロードされていますが、実際には同じ機能の代替バージョンである特定のプラグインが存在するため、2 つを切り替えることができることを知っておく必要がありますが、選択したものだけをメモリにロードしたい構成ペインから。
• ある時点で、プラグインをインストールするための 2 つの場所が必要になります。システム全体の場所 (たとえば の下のどこか/usr/local/bin/) とユーザー固有の場所 (たとえば の下のどこか/home/<user>/.myprogram/) です。

だから私の質問は本当に - おそらく - 3つです：

1. プラグイン コンテナー:私の目標にとって最も賢明な選択は何ですか? 単一のファイル？パッケージ？.py ファイルの単純なディレクトリ?)
2. 必ずしもプラグインをロード (インポート) せずにプラグインの存在を認識する: Python イントロスペクションを使用してそうするスマートな方法は何ですか?
3. プラグインを2つの異なる場所に配置する:それを行うための標準的な方法/ベストプラクティス(少なくともgnu/linuxの下)はありますか?

ほとんどのデータをサード パーティから受け取るアプリケーションがあります。これらのデータ セットの 1 つがトランザクション リストです。このサービスに書き込むことはできませんが、自分のアプリケーションで使用するためにそのデータにさらに情報を追加したいと考えています。拡張情報を含む SQL テーブルでそれを行うつもりです。

問題は、サードパーティのデータがレコード識別子を返さないことです。つまり、追加データの主キーとしてサードパーティの主キーを使用することはできません。可能であれば、明らかにそのキーを使用して拡張データを保存します。

たとえば、返されるデータは次のとおりです。

クライアント ID はこのテーブルでは一意ではありませんが、残りの情報は全体として一意であることが保証されています。

データを追加したい。例えば：

私は、他のすべての情報のハッシュである主キーを使用するという考えをいじりましたが、そのデータのクエリは、私が見る限り非常に非効率的です。たとえば、画面に 100 件のトランザクションを表示したいとします。そのためには、サード パーティからデータを取得し、各レコードをハッシュし、100 個のキーのいずれかを使用してすべてのデータをローカル データベースにクエリする必要があります。

誰か提案はありますか？

UML を使用してソフトウェア設計を学習するためのリソース (ケース スタディ、本)

私のクラスには次のコンストラクタがあります

ご覧のとおり、6 つのパラメーターがあります。このコードを見て、先輩の 1 人が、6 つのパラメーターを渡す代わりに、構成オブジェクトを渡すほうがよいと言いました。

私がこのようにコードを書いたのは、最近「依存性注入」について読んだことがあるからです。したがって、構成オブジェクトを渡すことは原則に反すると思います。

「依存性注入」の私の解釈は正しいですか? または先輩のアドバイスに従うべきですか？

マルチユーザーアプリケーションでユーザーにアクセス許可を割り当てることと、ビジネスロジックとの境界をどこで描くのかを知りたいです。

たとえば、ユーザーが複数の車にアクセスする権限を持つことができる場合、これらの権限をユーザーの車オブジェクトのコレクションに追加してユーザークラスから直接割り当てるか、ACLで割り当ててACLを使用して取得しますか？ユーザーがアクセスできる車のリスト？

この種のことのためにACLをいつ使用すべきか、そしてそれをビジネスロジックの一部にするべきかについてのガイドラインはありますか？