タグ付けされた質問 「separation-of-concerns」

質問で使用されている例では、最小限のデータを関数に渡し、ユーザーが管理者であるかどうかを判断するための最良の方法に触れています。一般的な答えは次のとおりです。 user.isAdmin() これにより、コメントが何度か繰り返され、何度も投票されました。 ユーザーは、管理者であるかどうかを決定するべきではありません。特権またはセキュリティシステムが必要です。クラスに密接に結合されているからといって、それをそのクラスの一部にすることは良い考えではありません。 私は答えた、 ユーザーは何も決定していません。ユーザーオブジェクト/テーブルには、各ユーザーに関するデータが格納されます。実際のユーザーは、自分に関するすべてを変更することはできません。 しかし、これは生産的ではありませんでした。明らかに、遠近法には根本的な違いがあり、それがコミュニケーションを難しくしています。誰かがuser.isAdmin（）が悪い理由を説明し、それが「正しく」行われたように見えるものの簡単なスケッチを描くことができますか？ 本当に、私はそれが保護するシステムからセキュリティを分離することの利点を見ることはできません。セキュリティに関するテキストには、セキュリティを最初からシステムに組み込む必要があり、開発、展開、保守、さらには寿命のあらゆる段階で考慮する必要があると書かれています。側面にボルトで固定できるものではありません。しかし、このコメントに対するこれまでの17の賛成票は、私が重要な何かを見逃していると言っています。

55 design  object-oriented-design  separation-of-concerns  permissions 

これは私のコードでも同僚のコードでもないということで、これを序文にしましょう。数年前、私たちの会社が小さかったとき、私たちには必要なプロジェクトがいくつかありましたが、その能力はありませんでしたので、それらは外部委託されました。今、私は一般的にアウトソーシングや請負業者に対して何もありませんが、彼らが生産したコードベースは大量のWTFです。とはいえ、（ほとんど）動作するので、私が見た外部委託プロジェクトの上位10％にあると思います。 会社の成長に伴い、社内での開発をさらに進めようとしました。この特定のプロジェクトは私の膝に着地したので、私はそれを調べ、掃除し、テストを追加するなどしてきました。 繰り返し見られるパターンが1つありますが、非常に驚​​くほどひどいので、理由があるのではないかと思って、見ないだけです。パターンは、パブリックメソッドやメンバーを持たないオブジェクトであり、オブジェクトのすべての作業を行うパブリックコンストラクターにすぎません。 たとえば、（コードがJavaである場合、それが重要ですが、これがより一般的な質問であることを願っています）： public class Foo { private int bar; private String baz; public Foo(File f) { execute(f); } private void execute(File f) { // FTP the file to some hardcoded location, // or parse the file and commit to the database, or whatever } } 疑問に思っているなら、このタイプのコードはしばしば次のように呼ばれます： for(File f …

49 language-agnostic  separation-of-concerns  constructors 

データベースはデータレイヤーに属しているのに対し、ストアドプロシージャはビジネスロジックであるため、データベース内のストアドプロシージャにビジネスロジックがあると、3層分離アーキテクチャに違反するという話を私の同僚から受けました。 ストアドプロシージャがなければ、世界は非常に厳しい場所になると思います。 彼らは本当に3層分離に違反していますか？

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

私の質問は、Microsoftによって導入されたMVCデザインパターンとRazor Syntaxに関連しています。 MVCの設計パターンを学習している間、私はこの考えは「懸念の分離」として知られる原則に基づいていると言われました。 ただし、Razor構文を使用すると、ビューで C＃を直接使用できます。 これは懸念事項の交差点ではありませんか？

22 c#  asp.net-mvc  separation-of-concerns  razor 

私にとって長年の疑問は、いつデータベーステーブルにデータ（実際の値）を保存し、いつコードに保存するのかということです。 知られていないコンセンサスは、通常そのようなものでした（*）： 単一の変数または単純な構造、またはいくつかの値の配列である場合、コードにデータを直接入れます。 [* コンセンサスはコメントと回答で議論されていますが、基本的には、質問を開始するための何らかの前提を望んでいたので、気軽に挑戦して改善してください] 例： $number = 44; $colors = array("blue", "yellow", ... "mauve"); 同じタイプの数百行以上のデータがある場合は、データベースを使用します。 しかし、灰色の領域があるようです。それほど明確ではないケースはどうですか？決定を下すために注意を払う必要がある考慮事項と要因は何ですか？ 例： 会社が「412T」として表すことができる10〜15種類のモーターフレームを使用しているとします。あなたはそれらの約30を持っています、そして、彼らはめったに変わりません。それらのDBテーブルを作成するか、データベースにハードコーディングできます。この場合、モーターは静的で物理的なものであり、頻繁に変更されることはありません。 それらをコードに保持すると、ソース管理の対象となります。データベースでは、通常、DBの変更は追跡されません。しかし、それらをデータベースに保持すると、コードをデータから解放（分離）できます。 私が使用できる別の（実際の）例は、私の質問です：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（現在48オプションデータの行）。

17 database  source-code  separation-of-concerns 

インライン、テキストのメタデータを保存する必要があるアプリケーションを開発しています。つまり、長いテキストがあり、特定の単語またはテキストの文に関連するメタデータを保存するとします。 この情報を保存する最良の方法は何でしょうか？ 私が最初に考えたのは、テキストを検索するときに解析されるMarkdown構文を含めることでした。次のようなもの： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[@note this sounds really funny latin] euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. これにより、私が考えることができる2つの問題が発生します。 比較的小さいのは、前述の構文が偶然にも前述のテキストにあった場合、構文解析を混乱させる可能性があるということです。 最も重要なのは、このメタデータがテキスト自体とは別に維持されないことです。 クエリ、統計、並べ替えなどの個別の方法でそれらを使用できるように、これらのメタデータが格納されている異なるDBテーブルなど、このデータを保持する個別のデータ構造が必要です。 編集：回答者が答えを削除したので、この最初の概念を拡張した実用的な提案だったので、ここに彼の提案を追加するのが良いと思います。ポスターは似た構文を使用するが、これにメタデータをリンクすることが示唆PRIMARY KEYのmetadataデータベーステーブル。 このように見えるもの： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[15432] euismod tincidunt …

14 data-structures  concepts  separation-of-concerns  markup 

AOPを利用して、ビジネスロジックからロギングコードを削除できます。しかし、それは単純なもの（つまり、メソッドの入り口/出口およびパラメーター値のロギング）をログに記録するためにのみ使用できると思います。 ただし、ビジネスロジックに何かを記録する必要がある場合はどうなりますか？例えば public void SomeDomainMethod(string id) { //Get user by Id User user = Users.Get(id); if (user == null) { Log.Warn("user is not existed"); //<----------------- Log A throw new InvalidOperationException("user is not existed"); } //Step 1 while(true) { //do something } Log.Info("Step 1 is completed"); //<----------------- Log B //Step 2 …

12 c#  logging  separation-of-concerns 

そうだった 長年にわたって、ソフトウェアソリューションを次のように整理してきました。 データにアクセスするビジネスを抽象化するデータアクセス層（DAL） ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー（BLL） ユーティリティ（Util）は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。 もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。 今のやり方 過去4年ほどの間、私はMicrosoftのEntity Framework（私は主に.NET開発者です）を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私のDALが使っていた仕事：データベースに対してCRUDを実行するビジネスを抽象化します。 したがって、通常、次のようなメソッドのコレクションを持つDALになります。 public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 次に、BLLでは、このメソッドは次のように使用されます。 public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } BLLには通常、さらに数行のロジックが適用されるため、これはもちろん簡単な例ですが、そのような限られた範囲でDALを維持するのは少し過剰に思えます。 DALを放棄して、単にBLLメソッドを次のように記述する方が良いと思いませんか。 public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns 

まず、私は1974年の「科学的思考の役割について」の抜粋エズガーW.ダイクストラの論文を読みました。 私にあなたに説明しようと思います、私の好みに何がすべてのインテリジェントな思考に特徴的です。それは、自分の一貫性を保つために、自分の主題の側面を分離して詳細に研究することをいとわないことです。常に、側面の1つだけで自分を占有していることを知っています。私たちはプログラムが正しい必要があることを知っており、その観点からのみそれを学ぶことができます。また、効率的である必要があることもわかっており、いわば、別の日にその効率を調査することができます。別の気分では、プログラムが望ましいかどうか、またそうである場合、なぜプログラムが望ましいかを自問することがあります。しかし、これらのさまざまな側面に同時に取り組むことによって何も得られません-逆に！-。それは私が時々「懸念の分離」と呼んだものであり、それは完全に可能ではないにしても、私の知る限り、思考を効果的に順序付けるために利用できる唯一の手法です。これは、「ある側面に注目する」という意味です。他の側面を無視することを意味するのではなく、この側面の観点から見れば、他の側面は無関係であることを正当化するだけです。それは1つと複数のトラックを同時に気にしています。 私は、コードをモジュール化することについて、現代の懸念の分離が語られているのを見ています。しかし、上記の引用を読んで、私はこれをあなたの心を一度に1つの特定のタスクに集中させ、他の側面に焦点を合わせないものとして理解します。これは、必ずしもコードをモジュール化されたチャンクに分離する必要があることを意味するわけではありません。 つまり、1つのファイルに、ビュー、リポジトリ、コントローラー、イベント処理、ファクトリーなどの概念がすべて1つのファイルにあるというコードが目の前にあるとします。 簡単な例として、データアクセスと表示（出力）を行うコードを次に示します。 $sql = "SELECT * FROM product WHERE id = " . db_input($id); $row = db_fetch_array(db_query($sql)); <option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option> モダンなオブジェクト指向を使用して、リポジトリパターンを使用して独自のファイルにデータアクセスを配置し、ビューコードを独自のファイルテンプレートに入れ、それらをまとめてコントローラー（またはアクションまたはリクエストハンドラー）を介して通信することができます。ファクトリーを追加して、さまざまな依存関係を作成して接続します。そして、それらのファクトリーを定義する構成ファイルを持つことができます。確かに、それは単一ファイルのすべてから一歩離れています。 懸念の分離に関する私の質問は次のようなものです。ダイクストラの引用を読んで、おそらく彼が懸念の分離を必ずしも「コードのモジュール化（ファイルまたは独自の関数/メソッド/その他への）分離」であるとは限らないという考えを得ました。また、コードで物理的に分離されているかどうかに関係なく、他の重要であるが現時点では検討されていない側面に集中することなく、プログラムの側面に集中することを意味しました。 では、なぜ、物理的なモジュラーコードの分離と設計パターンに負担をかけているのでしょうか。コードがどのように構造化されているかに関係なく、アスペクトに専念するだけでは十分ではありませんか？ 私は最も恐ろしいスパゲッティコードを書くことについて話しているのではなく、その側面のみを検討しているので、それはおそらく負担になります。しかし、結局のところ、私が目指しているのは、物理的なコード分離を実行する理由であり、側面に精神的に集中する必要がないのに、なぜコードを個別のファイルまたはチャンク（メソッド）に分割するのか、です。 懸念の分離は、肉体的ではなく精神的な運動のままである必要がありますか？ 言い換えれば、プログラミングの精神的側面（焦点を当てる）と物理的側面（紙面上のコード）の間に断絶があるべきでしょうか？

9 design  source-code  separation-of-concerns  modularization  dijkstra 

私はすっきりしたコードが大好きで、コードを可能な限り最善の方法でコーディングしたいと思っています。しかし、常に1つありましたが、本当に理解できませんでした。 メソッドに関する「懸念の分離」が多すぎるのはいつですか？ 次のメソッドがあるとします。 def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as file: line_number = 0 for line in file: if keyword in line: line_number = line return line_number この方法はそのままでも問題ないと思います。それはシンプルで読みやすく、そしてその名前が言うように、それは明らかにそうです。しかし、それは「ただ1つのこと」を実際に行っているのではありません。実際にファイルを開き、それを見つけます。それは私がそれをさらに分割できることを意味します（「単一の責任の原則」も考慮する）： バリエーションB（まあ、これは何となく理にかなっています。このようにして、テキスト内のキーワードの最後の出現を見つけるアルゴリズムを簡単に再利用できますが、「多すぎる」ように見えます。理由は説明できませんが、「感じる」 「それはそのように）： def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as text_from_file: line_number = find_last_appearance_of_keyword(text_from_file, keyword) return line_number def find_last_appearance_of_keyword(text, keyword): line_number = 0 …

9 single-responsibility  encapsulation  separation-of-concerns 

多くのビジネスロジックを処理する新しいアプリケーションを設計しています。 時間の経過とともにこのようなシステムに潜入することが多い、さまざまなアプリケーションレイヤー間の通常の絡み合いを回避するために、最初から問題の明確な分離を実装したいと思います。大まかに言えば、私は分離したいです： プレゼンテーション層 ビジネスロジックレイヤー データストレージと永続化レイヤー 私が最も苦労しているのは、特にビジネス層とデータ層の間で、実際にエッジで動作をきれいに実装する方法です。データレイヤーがORMオブジェクトをコアレイヤーに渡し、ビジネスロジックをORMに効果的に密結合するアプリケーションが多すぎます。 ORMオブジェクトをシリアル化された形式（JSON？）に変換してから、ビジネスレイヤーでそれを非シリアル化して、そのレイヤー内部のデータ構造にする必要がありますか？それは多くのオーバーヘッドではありませんか？ 中規模アプリケーションの懸念の分離をきれいに実装するにはどうすればよいですか？何かアドバイス？

9 design  separation-of-concerns  modularization