タグ付けされた質問 「application-design」

私は、ほとんどのビジネスロジックがデータベースに実装されているプロジェクト（主にストアドプロシージャを使用）で働いてきました。一方、仲間のプログラマーからは、これは悪い習慣だと聞いたことがあります（「データベースはデータを保存するためにあります。アプリケーションは残りを行うためにあります」）。 これらのアプローチのどれが一般的に優れていますか？ 私が考えることができるDBにビジネスロジックを実装することの長所は次のとおりです。 ビジネスロジックの集中化。 アプリケーションの種類、プログラミング言語、OSなどの独立性。 データベースは、テクノロジーの移行や大きなリファクタリング（AFAIK）を受けにくい傾向があります。 アプリケーションテクノロジの移行に関する手直しはありません（例：.NETからJava、PerlからPythonなど）。 短所： SQLは、ほとんどのアプリケーション指向言語が提供するライブラリと言語構成の欠如により、ビジネスロジックプログラミングの生産性が低く、より複雑です。 ライブラリ経由でのコードの再利用がより困難です（可能な場合）。 生産性の低いIDE。 注：私が話しているデータベースは、SQL Server、Oracle、MySqlなどのリレーショナルで人気のあるデータベースです。 ありがとう！

107 database  application-design  business-logic  business-rules 

私は現在取り組んでいるサイドプロジェクトのプロトタイピング/概念実証フェーズの終わりに近づいており、いくつかの大規模なアプリケーション設計の決定を決定しようとしています。このアプリは、アジャイル開発プロセス向けに調整されたプロジェクト管理システムです。私が下す必要がある決定の1つは、従来のマルチページアプリケーションとシングルページアプリケーションのどちらを使用するかです。 現在、私のプロトタイプは従来の複数ページのセットアップですが、backbone.jsを見て、Javascript（jQuery）コードに構造をクリーンアップして適用しています。Backbone.jsは複数ページのアプリケーションで使用できますが、単一ページのアプリケーションでさらに輝いているようです。単一ページのアプリケーション設計アプローチを使用することの利点と欠点のリストを考えています。これまでのところ： 長所 すべてのデータは何らかのAPIを介して利用できる必要があります。これは、アプリケーションにAPIを保持したいので、ユースケースにとって大きな利点です。現在、データの取得/更新の呼び出しの約60〜70％がREST APIを介して行われています。単一ページのアプリケーションを実行すると、アプリケーション自体がREST APIを使用するため、REST APIをより適切にテストできます。また、アプリケーションが成長するにつれて、API自体も成長することを意味します。これはアプリケーションが使用するものだからです。APIをアプリケーションのアドオンとして維持する必要はありません。 より応答性の高いアプリケーション-最初のページの後に読み込まれるすべてのデータは最小限に抑えられ、コンパクトな形式（JSONなど）で送信されるため、データ要求は一般に高速であり、サーバーの処理はわずかに少なくなります。 短所 コードの複製-たとえば、モデルコード。サーバー側（この場合はPHP）とJavascriptのクライアント側の両方でモデルを作成する必要があります。 Javascriptのビジネスロジック-これが悪い理由について具体的な例を挙げることはできませんが、だれでも読むことができるJavascriptのビジネスロジックを持っていると感じることはできません。 Javascriptのメモリリーク-ページがリロードされないため、Javascriptのメモリリークが発生する可能性があり、デバッグをどこから開始すればよいかさえわかりません。 また、両刃の剣のようなものもあります。たとえば、単一ページのアプリケーションでは、アプリケーションが特定の要求に必要な最小限のデータを要求するため、各要求で処理されるデータは大幅に少なくなりますが、サーバー。それが良いことなのか悪いことなのかはわかりません。 単一ページWebアプリケーションの長所と短所のうち、プロジェクトにどの方向に進むべきかを決定するときに留意すべきことは何ですか？

52 web-applications  application-design 

これを求める別の方法は次のとおりです。なぜプログラムはモノリシックになる傾向があるのですか？ Mayaのようなアニメーションパッケージのようなものを考えています。人々はさまざまなワークフローに使用します。 アニメーション機能とモデリング機能を独自の個別のアプリケーションに分割し、それらの間でファイルをやり取りして個別に開発した場合、それらの保守は容易ではないでしょうか？

48 design  architecture  maintainability  application-design 

私は仕事で新しいプロジェクトを始めており、おそらくプロジェクトのほぼ唯一の開発者になりますが、他の1人または2人の開発者は、既存のアプリケーションまたは単純なスクリプトをメインプロジェクトに統合する必要があります。このプロジェクトでは、小規模のバルクデータとストリーミングデータの取り込み/処理、およびイベント駆動型とオンデマンドの両方のコード実行を処理する必要があります。フレームワークの一部はCPUに強く依存し、一部はI / Oに強く依存します。ほとんどのデータは単一のマシン上に存在する必要がありますが、クラスターを作成してVMを接続し、利用可能な計算能力を向上させることができます。おそらく、このコアフレームワークが提供するサービスに依存する1つ以上の小さなWebアプリケーションがあるでしょう。主な言語は、ほぼすべてのPythonです。 私の質問は、開発の大部分を自分で行うことを考えると、このような取り組みにマイクロサービスアプローチを採用すべきか、モノリシックアプリケーションに固執すべきかということです。私の考えでは、マイクロサービス（Namekoを使用）は、異なる実行モデル（データパイプライン、イベント起動、オンデマンド、Webアプリケーションなど）を持つフレームワークの要素を自然に分離し、ワークロードと複数のプロセスにわたる通信。私の懸念は、おそらくシステムの実行を容易にするために必要な複数のサービス（rabbitmq、redisなど）を管理するKubernetesクラスター（私はDockerに精通していますが、Kubernetesにはまだかなり新しい）になることです。そして、潜在的に私たちが必要なすべての機能を実際に実装するための多くの小さなコードの塊 開発者が1人しかいないプロジェクトの場合、マイクロサービスはこのような複雑なシステムの開発と保守を引き続き簡素化しますか？代わりに使用することを検討する必要があるメソッド/システム/フレームワークはありますか、またはこの方法でシステムを設計する際のオーバーヘッドを削減するためにありますか？

30 python  microservices  application-design 

質問に正しいタイトルを付けることができない場合があります。しかし、ここにあります、 資産管理のための金融ポータルを開発しています。10000以上のクライアントがアプリケーションを使用することを期待しています。ポータルは、株式市場のテクニカル分析に基づいて、さまざまなパフォーマンス分析を計算します。 データベースを介して、ストアドプロシージャ、ユーザー定義関数、トリガーなどを通じて多くの機能を開発しました。C＃コードを使用するよりも、データベースで直接作業を行うことで、パフォーマンスを大幅に向上できると考えました。そして、実際にパフォーマンスが大幅に向上しました。 CTOの功績について自慢しようとすると、コードではなくデータベースに機能を実装するという私の決定に疑問を呈しました。彼によると、そのようなアプリケーションにはスケーラビリティの問題があります。彼の言葉では「最近のものはメモリ/キャッシュに保存されます。クラスター化されたデータは時間の経過とともに管理するのが難しくなります。また、機能はデータベースから完全に分離する必要があります。」 彼の言うことが正しいかどうかについて、いくつかの提案をお願いします。そのようなアプリケーションを設計する方法は？

17 architecture  database  application-design 

アプリケーションの設計と開発の傾向は、「ガッツ」から始まっているようです。ドメイン、データアクセス、インフラストラクチャなどです。通常、GUIはプロセスの後半に来るようです。最初にGUIを構築するのが役に立つのではないかと思います... 私の理論的根拠は、少なくともプロトタイプGUIを構築することで、舞台裏で何が起こる必要があるかをよりよく理解できるため、ドメインとサポートコードで作業を開始するためのより良い位置にいるということです。 サポートコードがまだ記述されていない場合、GUIレイヤーが実際に行うことはあまりないという点で、このプラクティスの問題を見ることができます。おそらく、モックオブジェクトまたはスローアウェイクラス（ユニットテストで行われているようなもの）を構築すると、最初にGUIを構築するのに十分な基盤が提供されます。 これは実際のプロジェクトにとって実行可能なアイデアかもしれませんか？GDD（GUI Driven Development）を頭字語stableに追加できるかもしれません...

17 gui  application-design  layers 

特定のランドマークの10 km /マイル（この話では重要ではありません）内のすべてのランドマークを見つけるジオ検索プロジェクトから始めようとしています。 たとえば、1,000,000のランドマークのデータベースがあるとします。特定の座標を持つランドマークの10マイルの範囲ですべてのランドマークを見つけるには、検索からのランドマークと1,000,000ランドマーク間の距離を計算する必要があります。 それを行うより良い方法はありますか？ 私が考えていた代替手段は、国、地域、都市、近隣、ビジネス、歴史などのランドマークを、ビジネスが近隣または都市の一部になることができるように分類することです。都市は、地域、国などの一部です。これにより、計算のリストを絞り込むことができますが、検索を高速かつ正確にするためには、多くの作業を行う必要があります。 Google Maps APIは役立ちますか？

14 c#  application-design  geolocation  google-maps 

私は少し最近成長しているDjangoプロジェクトにしばらく取り組んできました。取り扱いを容易にするためにどの戦略を使用するかについて少し考えてきました。入力を行いたいことの1つは、アプリケーションをいくつかの小さなアプリケーションに分割する必要があるかどうかです。それにより、ビューとモデルファイルが小さくなり、懸念事項の一部が分離されます。 これに悩まされることの1つは、私のアプリケーションでは、アプリケーション間で使用されるいくつかのヘルパーメソッドがあることです。また、一部のモデルはアプリケーション間で共有/使用する必要があります。これは理にかなっていますか？これは、アプリをいくつかの小さなアプリに分割することで達成したいと思っていた懸念の分離にはうまくいきません。アプリケーション間でヘルパーメソッド、モデルなどを共有するための良いアプローチは何でしょうか？

14 django  application-design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 Clojureをしばらく使ってきましたが、重要なプロジェクトでは使用していません。基本的に、構文といくつかのイディオムに慣れてきました。OOPのバックグラウンドから来て、Clojureが私が非常によく見た最初の関数型言語であるため、私は当然、物事の関数型の方法にそれほど満足していません。 とはいえ、大規模な機能アプリケーションの作成に共通する特定のワークフローやデザインパターンはありますか 「実際に」関数型プログラミングの使用を開始したいのですが、現在の専門知識の不足により、大失敗に終わるのではないかと心配しています。 「4つのギャング」はOOプログラマーにとって非常に標準ですが、機能的なパラダイムにより向けられた類似のものはありますか？私が見つけたほとんどのリソースには、優れたプログラミングナゲットがありますが、一歩踏み込んで、より広範な、よりアーキテクチャ的な外観を与えることはできません。

13 design-patterns  functional-programming  application-design 

私が取り組んでいるAPIには、IDの配列を受け入れる一括削除操作があります： ["1000", ..., "2000"] 削除操作は自由に実装できたので、すべてをトランザクション対応にすることにしました。つまり、1つのIDが無効な場合、リクエスト全体が失敗します。これを厳密モードと呼びます。 try{ savepoint = conn.setSavepoint(); for(id : IDs) if( !deleteItem(id) ){ conn.rollback(savepoint); sendHttp400AndBeDoneWithIt(); return; } conn.commit(); } 別の方法（ソフトウェアスイートの別の場所で実装）は、バックエンドでできることを実行し、アレイでエラーを報告することです。ソフトウェアのその部分はより少ないリクエストを扱うので、理論的にはレスポンスが巨大な配列になることはありません。 リソース不足のサーバーで発生した最近のバグにより、コードを再度確認し、今は元の決定に疑問を抱いていますが、今回はベストプラクティスではなくビジネスニーズによって動機付けられています。たとえば、リクエスト全体が失敗した場合、ユーザーは再試行する必要がありますが、いくつかのアイテムが削除された場合、ユーザーはアクションを終了し、管理者に残りの作業を依頼できます（バグの修正に取り組んでいる間） ！）。これが許容モードになります。 私はこの問題に関するガイダンスをオンラインで探してみましたが、手ぶらで出てきました。だから私はあなたに来ます：この種のバルク操作で最も期待されることは何ですか？もっと厳しくするべきですか、それとももっと寛容にすべきですか？

11 user-experience  application-design  transaction  failure 

私はこれに何度も遭遇しましたが、ここではやや誇張された最悪のシナリオがあります。 クライアントは、「この小さなタスクを実行するために、この小さなモジュールを作成してもらえますか」と言います。 私：「問題ない」。 そのため、予算や制約などに基づいて、設計の一部をスキップし、すぐに飛び込み、汗をかかないようにします。 次に、別のモジュールを要求します。そしてもう一つ。そしていくつかの機能強化。そして、これはすべて、長年にわたって非常にゆっくりと起こります。そして、あなたがそれを知る前に、あなたは恐ろしく設計されたこのモンスターアプリケーションを持っています。 何か小さなことをするように頼まれたらどうしますか？それが成長し続けるかどうかはわかりません...クライアントが追加を要求し続けるなら（そして、どちらもしません）。 結局のところ、それは単なる小さなアプリケーションであるため、オーバーアーキテクトすることはできません。あなたが言うなら（私はすべての声を知っているということで） -o-the-lineセキュリティと懸念の分離。実際、このことを本当に素晴らしいものにする、依存性注入ツールを使用してみましょう。 彼らは「そうだ」と言い、他の誰かに行きます。 予算、時間、認識は、アプリケーション自体の設計と同じくらい重要です。 これにどのようにアプローチする必要がありますか？ 質問は、「小さなアプリケーションのように見えるものの最終結果に関するすべての情報が得られない場合、アーキテクチャおよび設計の決定を早期に行うことを完全に回避する（または軽減する）方法」後で不適切ですか？

11 client-relations  application-design  systems-analysis 

ソフトウェアの「データ衛生」インデックスがあるべきか-プログラムがどれだけクリーンであるかを示すために？未使用の一時ファイル、レジストリエントリ、環境変数などを作成しない たとえば、Windowsのユーザーフォルダーを見ると、アプリケーションで使用されるあらゆる種類のワークスペースファイルが表示されます。 たとえば、これにより、何をバックアップする必要があり、何をマシン生成として破棄できるかを知ることが難しくなります。

11 environment  metrics  data  application-design 

現在、私は.NET Coreを研究しています。.NETCoreを最初に紹介した初期のドキュメントでは、さまざまな分野について話していることがわかります。これはこの写真のように見えます： すべての業種で、ランタイム、フレームワークが表示されますが、この「アプリモデル」も存在します。 また、.NET Core CLIに関するビデオを見ると、「DNXには独自のアプリケーションモデルがあり」、「。NET Core CLIは、クロスプラットフォームの.NETライブラリとコンソールアプリケーション開発のための単一の.NETアプリケーションモデルを作成する」とも言われました。 私の質問は次のとおりです。この「アプリケーションモデル」とは何ですか。実際にはどのようなアプリケーションモデルがあり、具体的には何が作られていますか？

11 .net  applications  application-design  runtime  managed-code 

同じデータベースで同じデータを共有するアプリケーションがいくつかあります。コードの冗長性を最小限に抑えるために、データアクセス層は共有プロジェクトです。これにより、各プロジェクトが独自のデータアクセスを再コーディングする必要がなくなりますが、これも大きな問題になります。1つのチームがデータレイヤーを更新する必要がある場合、他のすべてのチームは変更をプルしてテストし、変更が何も壊れていないことを確認する必要があります。これは遅くて苦痛なプロセスです。 共有データレイヤーを削除し、各チームに独自のデータレイヤーを管理させるというアイデアについて考えましたが、問題は、すべてのチームが同じデータベースにアクセスするため、テーブルの変更がある場合でも、すべてのチームが関連するコードを更新します。 だから私の質問は、多くのプロジェクトが同じデータソースから追​​い出され、データベースまたはアクセスレイヤーへの変更の痛みを最小限に抑えるように、データとアクセスレイヤーをどのように設計できるでしょうか。

8 c#  database-design  application-design