問題タブ [web-architecture]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - .NET Entity Frameworkプロジェクトのレイアウト(アーキテクチャ)
私は、.NET Entity Frameworkプロジェクトを設計して、優れた階層型アプローチを実現するための最善の方法を決定しようとしています。これまで、プレイヤーが惑星を所有して操作するブラウズベースのゲームで試してみました。これが私がそれを持っている方法です:
Webサイト
これにはすべてのフロントエンドが含まれます。
C#プロジェクト-MLS.Game.Data
これには、すべてのデータマッピングを含むEDMXファイルが含まれています。ここでは他にあまりありません。
C#プロジェクト-MLS.Game.Business
これには、PlanetManager.csなどの「マネージャー」と呼ばれるさまざまなクラスが含まれています。惑星マネージャーには、MLS.Game.Dataから生成されたコードオブジェクトを返すgetPlanet(int planetID)など、惑星との対話に使用されるさまざまな静的メソッドがあります。
ウェブサイトから、私はこのようなことをします:
var planet = PlanetManager.getPlanet(1);
MLS.Game.Data(EDMXから生成)からPlanetオブジェクトを返します。それは機能しますが、フロントエンドがMLS.Game.Dataを参照する必要があることを意味するため、ある程度気になります。しかし、GUIはビジネスプロジェクトを参照するだけでよいといつも感じていました。
さらに、私のマネージャークラスは非常に重くなる傾向があることがわかりました。結局、数十の静的メソッドが含まれることになります。
だから...私の質問は-他のみんなはどのようにASPEFプロジェクトをレイアウトするのですか?
編集
しかし、もう少し後、私を悩ませている追加のアイテムがあります。たとえば、Planetオブジェクトがあり、これもウィザードから生成されたコードであるとします。私の惑星が特殊なプロパティを持っている必要があるときが来たらどうしますか?たとえば、惑星オブジェクトの他のプロパティに基づいたある種の計算である「人口」と言います。Planetから継承する新しいクラスを作成し、代わりにそれを返しますか?(うーん、それらのクラスはEFによって封印されているのだろうか?)
ありがとう
javascript - 静的HTMLを提供し、AJAX / JSONを使用してコンテンツを生成する利点は何ですか?
http://blog.urbantastic.com/post/81336210/tech-tuesday-the-fiddly-bits
UrbantasticのHeathは、彼のHTML生成システムについて次のように書いています。
UrbantasticのすべてのHTMLは完全に静的です。すべての動的データは、AJAXを介してJSON形式で送信され、Javascriptを使用してHTMLと結合されます。言い換えると、UrbantasticのサーバーソフトウェアはJSONを排他的に生成および消費します。HTML、CSS、Javascript、および画像はすべて、異なるサービス(バニラNginxサーバー)を介して送信されます。
プレゼンテーションとデータを物理的に分離しているので、これは興味深いモデルだと思います。私は建築の専門家ではありませんが、効率と安定性が飛躍的に向上するようです。
ただし、次のことが私に関係しています。
[主観的]Clojureは非常に強力です。Javascriptはそうではありません。別の目標のために作成された言語ですべてのコンテンツ生成を作成すると、多少の苦痛が生じます(CSSでJavascriptタイプのコードを作成することを想像してください)。彼がJavascriptを生成するためのマクロシステムを持っていない限り、HeathはおそらくJavaScriptとClojureを絶えず切り替えています。彼はまたたくさんのJSコードを持っているでしょう。おそらくClojureよりもはるかに多いでしょう。これは、パワー、迅速な開発、簡潔さ、そしてLISPベースの言語に切り替えるときに私たちが見ているすべての点で良くないかもしれません。
[パフォーマンス]これについてはよくわかりませんが、ユーザーのマシンですべてをレンダリングするのが遅れる可能性があります。
【アクセシビリティ】JSを無効にしている場合、サイトは一切ご利用いただけません。
[アクセシビリティ#2] JavaScriptでいっぱいになる動的データの多くは、クロスブラウザの問題を引き起こすと思います。
誰かコメントできますか?このタイプのアーキテクチャについてのあなたの意見を読んでみたいと思います。
参照:
web-architecture - ウェブサイトのコンテンツをどのように構成していますか?
シンプルに保ち、ルートフォルダーと、画像、javascript、フラッシュなどのフォルダーを 1 つ持つようにしていますか? 通常、自分のフォルダを何と呼んでいますか? ファイルの命名規則を定めていますか?
architecture - IBM Websphere、IBM Http Server、Load Balancer(またはDispacher)を使用したファームの構築
これらの製品をアーキテクチャ化してファームを作成する方法を学ぶためのWebページやPDF、または本を知っていますか?
また、一般的なWebアプリケーションファームアーキテクチャのベストプラクティスソースを高く評価しています...
特にIBM製品を使用した高可用性でスケーラブルなWebアーキテクチャーについて学びたいです...
hibernate - Web アーキテクチャ: MVC、遅延初期化、データ転送オブジェクト、ビューでセッションを開く、コンセンサス アプローチはありますか?
典型的な Web 3 層アプリケーションについて、次の設計 (および理想的なアーキテクチャの提案) にはどのような欠陥がありますか?
私の現在の青写真のアプローチは大まかにこれです(Java、Spring、Hibernate、JSPを想定)
コントローラ
ステートレスで、(遅延初期化例外を回避するために) 読み取り専用トランザクションでラップされる可能性があり、サービスのみを介して永続ストレージからエンティティを取得し、それらをモデルとしてビューに渡します。それらに対してビジネス ロジックを実行し (BL はサービス レイヤーにのみ存在する必要がありますか?)、必要に応じて永続化のためにサービス レイヤーに戻します。
長所: 読み取り専用のトランザクション ラッピングの場合 - 1 つの接続のみ、同じ永続エンティティに対する冗長なヒットがない、クエリ キャッシュをより適切に利用する、サービス レイヤーが要求パラメーターを「認識」してはならない、または必要な init グラフ スパンを使用しない、lazy init 例外を回避する。
短所: 読み取り専用のトランザクション アプローチはリスクが高い可能性があります。コントローラーは理想的なビジネス ロジックのぶら下がり場所ではありません... JUnit を実行するのは非常に困難です (入力は要求です...)
意見
非トランザクション (非遅延コレクション/メンバーへのアクセスは、遅延初期化例外になります)
長所:
ビューの作成者は、単なるドット表記によってアプリケーションのパフォーマンスに影響を与えるべきではありません (たとえば、大規模なコレクションの遅延初期化による N+1 選択の原因)。
また、切断されたクライアント (Flex またはその他のリッチ クライアント) では、リモートでの遅延初期化はサポートされていないか、賢明なことではありません。
短所: コントローラー / サービス / DAO は、ビューのエンティティの適切なグラフを慎重に準備する必要があり、オーバーシュート (パフォーマンス) / アンダーシュート (遅延初期化例外) になる可能性があります。エンティティ グラフを初期化できる順列の数にはデカルト積があるため、無数のサーバー側メソッドが混乱を引き起こす可能性があります。
モデル
永続オブジェクトをそのまま (データ転送オブジェクトなし) 使用すると、状態がセッションに保存されます。
長所: POJO を書き直す必要がない、既存のエンティティを再利用する、セッション状態は非表示フィールドの状態処理よりも安全です。
短所: 切断されたフレームワークには不向きです。切断された古いオブジェクトを保存するリスク、ロックの問題のリスク、他のデータの上書きのリスク、楽観的ロックが必要な場合があります。
サービス
トランザクショナルで、リクエスト スコープがわからないため、実際の永続ストレージ アクセスのために DAO レイヤーを呼び出します。これは、古典的に BL があるべき場所ですが、BL がコントローラー側に何度も漏れているようです。
ダオ
アトミック永続ストレージ ファサード、BL を無視、または任意のコンテキストを含む
最後に、質問:
上記のアーキテクチャで何を修正しますか?
(私のように)それは非常に一般的なアプローチだと思いますか(ビュー内のオープンセッションなど、いくつかの小さな違いがあります)?それとも、あなたがそれを見るのは初めてで、私は何かひどく間違った (または正しい) ことをしているのですか?
アプリケーションでどのように解決しますか? モデルとビューにもエンティティ POJO を使用していますか? それとも、より単純な UI Bean に接続しますか (すべて完全に初期化され、安全です)。
これは主観的な質問かもしれませんが、1 つ、2 つ、または 3 つの最大の一般的な「宗教」に集中する明確なベスト プラクティスの設計パターンがあると確信しています。
url - Web で mvc をルーティングする
アプリケーションの各「セクション」へのルーティング (および/またはアーキテクチャ) を改善する方法について、誰かが私にアドバイスを提供できるかどうか疑問に思っていました。(私はPHP5で書いていて、厳格なMVCを使おうとしています)
基本的に、私はアプリ用の一般的なインデックス ページを持っています。それは jquery や css などの定型文を吐き出し、サイト全体のメイン ナビゲーションも生成しますが、接続するための最良の方法についてはわかりません。 「メイン メニュー」項目 (ハイパーリンク) とそれに関連付けられたコントローラー。これまでは、URL に文字列を追加し、'switch' ステートメントを使用して正しいコントローラー (およびビュー) に分岐し、'$GET[]' から文字列を抽出して、対応するコードを実行させていました。アクション。たとえば、顧客データの基本的な crud システムがある場合、顧客の詳細を編集する URL は「www.example.com/index.php?page=customer&action=edit&id=4」のようになります。
このようにすることでセキュリティ上の問題が発生するのではないかと心配しています。また、ユーザーがリンクをクリックすると、メインの「index.php」ファイルをアクションごとに正しいコントローラーに分岐する代替手段がわかりません。
コントローラーの名前を偽装するために mod_rewrite を使用した方がよいでしょうか? または、関連するコントローラーを取得するために各 URL がフィルター処理される個別のルーティング システムがある ASP MVC フレームワークと同様のシステムを作成するには?
乾杯!
web-farm - Web ファームの Web アプリケーション アーキテクチャ
1 つの Web サーバーから 2 つ以上の Web サーバーに移行する場合、Web アプリケーションにいくつかの変更があることは知っています。しかし、アーキテクチャ上、ファームにサーバーを追加する際に考慮すべき他の変更はありますか? ファーム内のサーバーが増えると、展開がより複雑になることを理解しています。少し前のインタビューで、大規模な Web ファームを扱った経験が十分にないのではないかと懸念されたので質問します。3 台のサーバーは、私が使用した中で最大のものです。
css - 同様のサイト間で共有されるディレクトリ内の共通の共有 CSS JS ファイル?
背景情報: 複数の Web サイトをホストする ISS6 Web サーバーがあります。スタイルやレイアウトなどを共有する「姉妹」サイトと見なすことができる約 15 のドメインがありますが、それでも独自のカスタマイズ スタイルがあります。(これらの基本的なサイト以外はまだ作成していません)
したがって、問題は、各サイトの CSS と JS のかなりの部分が同じであるため、同じ IIS サーバー上のサイト間で共通のマスター CSS と JS ディレクトリを共有する方法にはどのようなものがあるでしょうか?
この共通ファイルのマスター ディレクトリをドメインの 1 つにホストし、そこからホストできることはわかっていますが、それは最も洗練されたオプションとは思えません。または、各ドメインに CSS および JS ファイルの独自のコピーを提供することもできますが、これはおそらく最悪の選択肢です。
バージョン管理ソフトウェアや Visual Studio は使用せず、notepad++ のみを使用しているため、開発者間でファイルを共有することにはあまり関心がありません。
ご意見ありがとうございます。
orm - データベースに依存しないレイヤーに接続するWebプログラムを作成することをお勧めしますか?
私は以前はWinformsプログラマーです。私は常に、作成するプログラムをフロントエンド(Winforms)とミドルティア(Remoting / WCFによって促進される)の2つの部分に分割します。
そのアプローチでは、フロントエンドコードはLinqまたはSystem.Data.SqlClientにアクセスできません。ただし、これには、中間層がインスタントSOAシチズン(サービス指向アーキテクチャー)であり、B2Bシナリオで使用でき、データベースに依存せず、単なるWinformsアプリであってもインターネット対応であるという追加の利点があります。
今、私はウェブスキルを学んでいます。本ProASP.NETMVCのSportsStoreプロジェクトを使用すると、その本の古い(?)アプローチ(中間層)とリポジトリアプローチを比較することは避けられません。リポジトリアプローチは、データアクセスメカニズム(Linq to SQL)をフロントエンド(SportsStore.WubUI)に直接公開します。リポジトリアプローチを使用すると、SportsStore.WebUIは引き続きデータベースに直接接続します。
質問は、Webプログラムで、フロントエンドを中間層にのみインターフェースすることを目指すべきか(つまり、フロントエンドはデータベースに依存せず、中間層はインスタントSOA市民になるべきか)、それとも私がすべきかということです。フロントエンドでデータベースを直接(リポジトリアプローチ、ORMなどを使用して)使用しますか?
asp.net-mvc - Page-Controllerパターンとは正確には何ですか?
ページコントローラーパターン(Microsoft .NETを使用したエンタープライズソリューションパターンで説明されているMVCパターンの改良)は、基本的に単純なURIページ要求(つまり、URI +フォーム送信+クエリ文字列)のパターンです。ASPは基本的に?それとももっと複雑なものですか。
誰?