問題タブ [anti-patterns]

ユーザーが終了ボタンを使用してウィンドウを閉じるのをブロックすることはできます[X]か? 私は実際に、ユーザーがウィンドウを閉じるための閉じるボタンをページに提供しています。基本的に、私がやろうとしているのは、ユーザーにフォームに入力して送信させることです。提出するまでウィンドウを閉じたくありません。

私はあなたのコメントに本当に感謝しています.私は商用ウェブサイトでホスティングするつもりはありません. これは内部的なものであり、実際には、私たちが設計したこの調査にすべてのスタッフを参加させています....

正しい方法ではないことはわかっていますが、ここで発生した問題の解決策があるかどうか疑問に思っていました...

これは、SOA の世界で定期的に繰り返される議論です。1995年くらいから聞いていましたが、それよりもずっと前から話題になっていました。私はそれについて間違いなく自分の意見を持っていますが、Data Services Layer を持つことについて、また同様に Data Services Layer を持つことに反対することについて、いくつかの適切で確固たる議論を聞きたいと思います。

システム アーキテクチャにどのような価値を追加しますか? 固有の落とし穴は何ですか？一般的なアンチパターンとは?

記事へのリンクは間違いなく受け入れられます。

混乱を避けるために、この記事では、私が話しているデータ サービス層のタイプについて説明します。基本的に、データへの SOAP アクセスを提供し、ビジネス ロジックを含まない、データベース上の薄いレイヤー。

これまでに見たことのないものがあります。データベースは本当に汎用的です。例: 具体的なタイプの代わりに、一般的なタイプのデバイスがあり、それはカスタム プロパティ テーブルに関連しています。

残念ながら、エンティティのモデルはこれらのテーブルを表しているため、モデルはビジネスについてまったく語っていません。

最後に、プログラミングは非常に混乱します。一般的なテーブルにあるはずのカスタム プロパティを誰も設計または定義していないため、どこに何を配置すればよいかわかりません。また、1 つの属性を取得するだけでも多くのコードが必要です。

汎用モデルを使用した汎用データベースは、ある種のアンチパターンだと思いますか? どんなプロ？

常に一般的なパターンにまとめようとしているので、アプリケーション全体でこれらすべてのランダムなプロパティを管理するための最良の方法や推奨される方法を見つけるのに苦労しています。私はいくつかのSOの知恵を探しています。

私が話しているランダムなプロパティは何ですか？ここに小さなリストがあります：

• ファビコン
• ロゴやソーシャルアイコンなどのランダムだが一般的なアイコンの代替テキスト
• メニュータイトルとネストされたメニュータイトル
• 著作権情報
• フォームとボタンのラベル
• フォームフィールドのデフォルトテキスト
• ツールチップ
• 「コメントを残す」、「メールを送信する」、「返信をキャンセルするには、ここをクリックしてください」などのテキスト。
• おすすめの投稿
• 著者名

私が取り組んだ最初の大きなプロジェクトは、Spree eコマースシステム（私はRailsの人です）をカスタマイズすることでした。彼らは、たとえば、htmlテンプレートで使用する深くネストされたyamlファイル<h1>t('checkout_steps.payment')</h1>にその構成要素の多く（すべてではない）を保持します。次に、settingslogicなどと同様に機能するものがあります。私はそれらのアプローチが好きですが、それが最善の方法であるかどうかはまだわかりません...

私は（以上に）疑問に思っています、どうやって、SOリーダー：

• 200以上のランダム設定を効果的に管理するようにコードを整理しますか？
• どんな制度がありますか？どんなパターンを使っていますか？
• クライアントにこれらを何らかの方法でカスタマイズさせますか？

正しい方向への微調整を探しています。プログラミングの方法を学ぶことから始めて、コードの分離とクラスの明示的な定義について学びます。物事を相互に結び付けて混乱させるのではありません。しかし、カスタム/ランダム設定/構成はこれらのルールのいずれにも従わないようであり、それらは完全に除外されています。だから私はあなたがそれらについてどう思うか疑問に思っています。コードを調べて、HTMLテンプレートのセット全体で値を変更するのが最善のオプションだとは思いません。

つまり、WTFは「設定」であり、どのように正しく使用するのでしょうか。

あなたの洞察を楽しみにしています。

アンチパターンについて多くのことを聞いたので、これに関する本を読みたいと思います。どの本をアンチパターンに提案しますか。

私はこの「デメテルの法則」について調べてきましたが、それ (および一般的な純粋な「ラッパー」クラス) は一般的にアンチ パターンのようです。実装クラスを考えてみましょう:

ここで、別のクラスの 2 つの異なる実装を考えてみましょう。

そして、上記のメソッドを呼び出す方法:

一見すると、バージョン 2 は少し単純に見え、「Demeter のルール」に従い、Foo の実装を非表示にするなどしています。たとえば、パラメーターをリセットに追加すると、次のようになります。

どちらのバージョンでも callingMethod を変更する必要がありますが、バージョン 2 では ScreenSpaceEffectsも変更する必要があります。誰かがラッパー/ファサードを持つことの利点を説明できますか (アダプター、外部 API のラップ、または内部 API の公開を除く)。

編集：些細な例ではなく、これに遭遇した多くの実際の例の1つ。

OK、StackExchange UI は、ユーザビリティに関する限り、私がこれまでに見た中で最高の Web サイトおよび全体的な GUI の 1 つだと述べている記録がありますが、3 部作には私を悩ませている特定の側面が 1 つあります。

例として、http://meta.stackoverflow.comにアクセスしてください。

上部のバナーを見てください (「リマインダー -- タイムゾーンによってはエイプリルフールです!」と表示されているバナー)。

個人的には、これは「ユーザーに作業を理解させる」アンチパターン (公式に呼ばれるものは何でも) であると感じています。モードが適切な場合は、モードを完全にオンにして、モードがオンになってはならない理由をユーザーに説明します (この特定の例では、モードはもちろん、00:00 で始まるユニコーンのグラバターを表示しています)一部のユーザーがまだ 3 月 31 日に住んでいるという事実にもかかわらず、最初のタイムゾーンで)。

Great Recalc も同じように処理されました。ユーザーに積極的に「担当者が X から Y に変更されました」と伝える代わりに、ほとんど目に見えない同じバナーがメタに表示されました。

したがって、質問は次のとおりです。

• そのような公式のアンチパターンはありますか？
• そのようなデザインのアンチパターンのよく知られた例は他にありますか?
• 私が作成したSOの例またはあなた自身の例をどのように修正しますか? 修正のパターンはありますか、それともケースバイケースの解決策でなければなりませんか?

シーケンシャル カップリングは、コードでは本当に悪いことですか?

これはアンチパターンですが、私が目にする唯一のリスクは、メソッドを間違った順序で呼び出すことですが、このアンチパターンを使用した API/クラス ライブラリのドキュメントはそれを処理する必要があります。シーケンシャルなコードには、他にどのような問題がありますか? また、このパターンはファサードを使用することで簡単に修正できるようです。

ありがとう

http://www.c-sharpcorner.com/UploadFile/dhananjaycoder/activedirectoryoperations11132009113015AM/activedirectoryoperations.aspxを見ると、1 つのクラスに AD のプロパティの膨大なリストがあります。

このような (関連する) フィールドの大きなリストをリファクタリングする良い方法は何ですか? 個別のクラスを作成するのは適切でしょうか、それともこれをより管理しやすくするためのより良い方法はありますか?

ありがとう

これを明確にしたいと思います。私がドメイン貧血と言うとき、私は意図的なドメイン貧血を意味し、偶然ではありません。私たちのビジネスロジックのほとんどが一連のサービスの背後に隠されている世界では、完全なドメインモデルが本当に必要ですか？

これは、「ドメイン」モデルが実際には永続性モデルであるプロジェクトに取り組んで以来、私が最近自問しなければならなかった質問です。どのドメインオブジェクトにもメソッドは含まれていません。これは非常に意図的な決定です。

最初は、本質的にタイプセーフなデータコンテナでいっぱいのライブラリを見たときに身震いしましたが、この特定のシステムは基本的なCRUD操作ではなく、基本的なCRUD操作を実行するのではないかと思ったので、この場合はこれが適切な選択です。 。私の問題は、これまでの私の経験がリッチドメインモデルに非常に焦点を合わせていたので、少し投げられたということです。

ドメインロジックの残りの部分は、別のアセンブリに存在するヘルパー、ファサード、およびファクトリのグループに隠されています。

これに対する人々の考えを聞きたいと思っています。明らかに、これらのクラスの再利用に関する考慮事項ははるかに単純ですが、それは本当に大きなメリットですか？