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

ソフトウェア設計による問題の解決とソリューションの計画に関する質問。

9
マルチスレッドファイルのコピー
ファイルをネットワーク共有の場所にアップロード(およびファイルに対して他の操作を実行)するために使用されるユーティリティがあります。 ファイルサイズは、数MBから500 MBに変化する傾向があります。 共有の場所にファイルをアップロードするときにマルチスレッドをサポートする必要があるという提案が出ました-バイトチャンクで行う必要はありません-各スレッドは1つのファイルを選択してアップロードを試行する必要があります。 マルチスレッドがこのようなIO操作を高速化できるかどうかは、私にはよくわかりません。私の勘は有効ですか? 確かにこの機能を構築する必要がある場合、ファイルコピーエンジンの設計にはどのようなアプローチが適しているのでしょうか。 robocopyなどのツールを使用することは理にかなっていますか(私はマルチスレッドをサポートする新しいバージョンを読みました)。 編集:遅延といくつかの重要な情報の欠落についての謝罪。 このユーティリティはC#(.Net 2.0)を使用して構築されており、今後のアップデートでも.Netを使用する必要があります(フレームワークのバージョンは制約ではありません)。ユーティリティはユーザーのマシンにインストールされます(WinXPの場合は約20)。ターゲット共有はWin2k3サーバー上にあります。 編集2:TPLを介したファイルのアップロードを実装する簡単なアプリケーションでいくつかのテストを実行することを決定しました。この分析を投稿して、先に進むかどうかを決定します。皆様のご協力に感謝いたします。

3
MVC Webアプリケーションで複雑なビュー(複数の部分から構成される)を処理する方法
MVCパターンを使用してブログWebアプリケーションを作成しているとしましょう。ブログアプリケーションのメインページの一般的なレイアウトは、メイン部分にある種の投稿インデックスであり、それ以外に、タイムライン、タグナビゲーションパネル、サブスクライブパネルなど、いくつかの追加部分があります。これらのコントロールは、単一の投稿ビュー。他のビューに表示される場合があります。 私の質問は-私のビューとコントローラーでこれらのパネルを別に処理する方法です。ここには3つのアプローチがあります。 ビュー(インデックスまたは単一の投稿)のレンダリングに必要なすべての情報を含む大きなviewmodelクラスを作成します。その場合、これらのサイドパネルを部分ビューにして、その大きなビューモデルの一部を渡してレンダリングされるビューから呼び出すことができます。欠点は、コードが重複していることを意味する、さまざまなコントローラーメソッド間でコードを埋めるviewmodelを使用することです。それはかなり悪いです。 ビューレンダリングの別のレイヤーを作成します。たとえば、レンダリングの最上位のレイヤーが、HTMLのレンダリング済みの部分、または呼び出されたときにHTMLを出力する関数を受け取ります。この「結合パーシャルレイヤー」の下のレイヤーは、メインコンテンツを含め、必要な各パネルのパーシャルビューを提供します。ここの欠点-メモリ使用量。ほとんどの最新のフレームワークはHTMLを直接出力ストリームにレンダリングしますが、このアプローチでは、部分ビューが最初に文字列オブジェクトにレンダリングされ、メモリのオーバーヘッドが発生します。 ビューからコントローラーメソッドを呼び出すasp.net mvcの「RenderAction」のようなものを使用します。これはMVCアプローチを落とすため、与えられた3の最悪のソリューションだと思います。 質問は特定のフレームワークに縛られているわけではありません。そのようなことを行う一般的な方法を理解したいと思います。 更新 答えが出た後、投稿が明確でないことがわかりました。ここで合理的な更新: 下でのviewmodelの用語私は、特定のビューをレンダリングするために必要なすべてのデータを含むオブジェクトを理解しています。 3つのアプローチはすべて、独自のビューモデルを使用して部分ビューを構築することを含みます。例(C#構文を使用): class SinglePostViewModel { string Text {get;set;} string Title {get;set;} string Slug {get;set;} DateTime PublishedDate {get;set;} ... } class TagNavigationPanelViewModel { string TagText {get;set;} int PostsCount {get;set;} } class CalendarNavigationPanelViewModel { DateTime YearAndMonth {get;set;} int PostsCount {get;set;} } 私の質問は、これらの部分的なビューをうまく組み合わせる方法です。

1
デスクトップアプリケーションおよびWebプロジェクトで使用される可能性のある共有ライブラリの作成
私は過去1年ほどの間、私たちの会社で多数のMVC.NETおよびc#デスクトッププロジェクトに携わってきましたが、他のプロジェクトにも(もちろん、読み取り専用の学習能力で)鼻を突っ込んでいました。 このことから、さまざまなプロジェクトやチームにわたって、優れたインターフェースや抽象化に対してうまく設計された機能がたくさんあることに気づきました。私たちは時々私たち自身の仕事を好む傾向があるので、私はいくつかのプロジェクトがまったく同じクラスを持っていることに気づきました。もともとそれを書いた) この事実については、時折プログラマーミーティングの1つで言及し、この機能の一部を企業のコアライブラリに組み込んで、長期にわたって構築して複数のプロジェクトで使用できるようにすることを提案しました。誰もが同意し、私はこの可能性を検討し始めました。 しかし、私はかなり早い段階で障害に遭遇しました。現在、私たちのチームは主にMVCに焦点を当てており、主に2.0にプロジェクトがありますが、3.0に分岐し始めています。また、いくつかの共有クラスや基本的なヘルパーメソッドの恩恵を受ける可能性のあるデスクトップアプリケーションもいくつかあります。 最初にこのDLLを作成するときに、すべてのプロジェクトタイプ(Web、クライアントなど)で使用できるいくつかの共有クラスを含めましたが、MVCアプリケーションでのみ役立ついくつかの共有モジュールの追加を検討し始めました。しかし、これは私が作成していたクラスのいくつかを活用するために、いくつかのMicrosoft Web DLLへの参照を含める必要があったことを意味しました(この段階ではMVC 2.0)。 今私の問題は、クライアントアプリケーションでも使用できるWeb固有のライブラリへの参照を持つ共有DLLがあることです。それだけでなく、DLLは最初にMVC 2.0を参照し、最終的にすべてのプロジェクトでMVC 3.0に移行します。しかし、このライブラリのクラスの多くはまだMVC 3などに関連していると思います このDLL内のコードは、次のような独自の名前空間に分離されています。 CompanyDLL.Primitives CompanyDLL.Web.Mvc CompanyDLL.Helpersなど だから、私の質問は: このような共有ライブラリを作成してもよろしいですか、またはWeb固有の機能が含まれている場合、特定のフレームワークまたはMVCバージョンのみを対象とする別のWeb DLLを作成する必要がありますか? 問題がなければ、たとえばMVC 3プロジェクトでMVC 2を参照するライブラリを使用するときにどのような問題が発生する可能性がありますか。ある種の互換性の問題、またはライブラリを使用している開発者がMVC 2.0ライブラリが必要であることに気付かない問題に遭遇するかもしれないと私は考えています。彼らはいくつかのジェネリッククラスなどを使いたいかもしれません コンセプトは当時は良いアイデアのように思われましたが、おそらく実際的な解決策ではないのではないかと考え始めています。しかし、テスト済みのコードであることが証明されているため、プロジェクト間でクラスやメソッドがコピーされるのを目にした回数は、完全に正直であることに少し不安を感じます! 更新:私が採用したBernardsの回答に加えて、良いアドバイスのようです。ただし、MVC 2とMVC 3の両方のプロジェクトでおそらく役立ついくつかの共有クラスを作成したいと思います。ただし、最初に共有クラスを作成するには、共有アセンブリがMVCフレームワークの1つを参照する必要があります。 上記の第2四半期をさらに詳しく説明します。 MVC 3 Webソリューションが必要な場合、MVC 3を具体的に参照するCompanyDLL.Web.Mvc3プロジェクトを共有する必要がありますか?これは、CompanyDLL.Web.Mvc2ソリューションからこの新しいMvc3共有プロジェクトにすべてのコードをコピーすることを意味しますか? 共有アセンブリの作成、および異なるフレームワークバージョンに対するビルドと参照の基本的な設計スキルが不足しているようです。または、それを吸い込んでCompanyDLL.Web.Mvc2、CompanyDLL.Web.Mvc3、CompanyDLL.Web.Mvc4などのライブラリを作成するだけの簡単な場合もあります...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.