26

CSLAフレームワークとその使用法とは何ですか？

4

6 に答える 6

80

170万のLOCコードベースを使用した私の経験からの私の意見：

  1. CSLAは、分散アプリケーション/データベース環境を対象としています。これが、基本的なビジネスオブジェクトがすべてを実行する理由です。たとえば、独自のデータ永続性です。オブジェクト（およびその状態にリモートで関連付けられているすべてのもの）は、シリアル化され、別のアプリケーションやデータサーバーに送信されて動作することを目的としています。
  2. 上記が解決する必要のある問題ではない場合、CSLAはやり過ぎです。私たちの開発チームは、CSLAにコミットしたことを後悔しています。
  3. 複雑なウィンドウUIですべてのCSLAボールをジャグリングするのは困難です。マルチタブの画面（サブ画面が開く場合があります）があり、データ入力の「左から右、上から下」のフローに従わず、頻繁に[保存]をクリックしない限り、不完全なデータを配置および/またはフェッチすることになります。データベースとの間で; または、入力したばかりのデータを完全に削除します。はい、元のコーダーに問題がありますが、CSLAにも問題があります... CSLA機能を有効にし、制御し、調整するための可動部分が非常に多いようです。本当に必要なのはセスナ152のようなものだけなのに、戦闘機のすべてのダイヤルとスイッチを処理しなければならないようなものです。
  4. CSLA機能を有効にするために、多くのカスタムコードを記述します。たとえば、CSLAは、HibernateやEntity Frameworkなどのオブジェクトリレーショナルマッパー（ORM）ツールと混同されることはありません。私たちのSAVE（）メソッドは自明ではないので、自明なものもそうです。
  5. コードジェネレーターの使用を奨励すると、問題が複雑になります。CodeSMithを使用して、データテーブルからクラスを生成しました。したがって、テーブルとc＃クラスが1対1で対応するコードになります。したがって、データストアを処理するためのすべてのコードを「実際の」オブジェクトに記述する必要があります。
  6. データストア/およびフェッチは、CSLAでは非常に非効率的です。巨大なモノリシックなBusinessObject-does-all-and-knows-all中心のパラダイムにより、オブジェクトは、一度に1つのオブジェクトのデータフェッチとインスタンス化を実行することになります。複合オブジェクトのコレクションは、問題を大幅に悪化させます。単一の「getthisobject」は、常に個別のデータフェッチのカスケード（個々のオブジェクトごとに1つ以上）を生成して、継承と複合関係チェーン全体をインスタンス化します。「N+1クエリ問題」として知られています。ああ、データをフェッチすると、既存のオブジェクトのみを更新している場合でも、常に新しいオブジェクトが作成されます。より複雑な画面がFUBARであることも不思議ではありません。

これにより、堅実なオブジェクト指向のプリンシパルと関心の分離を使用してアプリケーションを設計できます。

はいといいえ。ほとんどありません。

BusinessObjectは、独自のデータ格納を処理します。それは関心の分離に反対です。

「それはあなたを可能にします...」ええ、そうです-空白のテキストエディタ画面もそうですが、例えば、MVC.NETフレームワークのようにあなたを強制したり奨励したりすることはありません。IMHO、CLSAは、それを使用して開発するコードが「堅実なオブジェクト指向の原則」に従うことを保証するためのメリットをまったく提供しません。実際、弱いOOスキルを持つコーダー（私の経験では大多数）は、CSLAを使用すると本当に目立ちます！メンテナンスプログラマーは悲惨なことになります。

CSLAは、 継承よりも構成を優先する、ソリッドオブジェクト指向の原則のポスターの子です。 CLSAコードはテストできません。継承されたフレームワークBusinessObjectは、すべてを一度に、そして毎回必要としているため、多くのテストカバレッジを取得できる可能性はほとんどありません。すべてが緊密に結合されているため、断片を理解することはできません。フレームワークは依存性注入に適していません。それはコードの鉄のカーテンです。

コードのデバッグは困難になります。コールスタックは非常に深くなり、いわば太陽の中心に近づくと、すべてが反射に変わります-「*＆^＃メソッドが呼び出されたばかりですか？」そして、あなたは単に迷子になります。限目。

2016年3月7日編集

元の投稿の後に、さらにどのような洞察を追加できますか？おそらく2つのこと：

まず、CSLAにはある程度の見込みがあるように感じます。これらすべての可動部品を一緒にジャグリングする方法を知っていれば。しかし、CSLAは非常に謎めいたものであるため、私たちが正しく行ったことでさえ、時間の経過とともに破損します。非常に強力なチーム全体のCSLAがないIMHOは、実装が運命づけられています。技術的な参考資料、トレーニング、コミュニティの活気に満ちた「オープンソース」がなければ、それは絶望的です。私の最終的な分析では、ほぼ10年で、CSLAコードは技術的負債を悪化させています。

次に、私が最近行ったコメントを以下に示します。

私たちの複雑さはCSLAインフラストラクチャに適合しないように思われることが多いため、フレームワークの外部で記述します。この安価な労働力はSRP違反を蔓延させ、たとえば動的ルールの適用を管理するレンガの壁にぶつかります。次に、CSLA親/子インフラストラクチャは複合オブジェクト検証を伝播しますが、常にc / p関係が必要なわけではないため、さらに検証を記述してコードを格納します。そのため、今日、CSLAの実装は一貫性がなく混乱を招いています。より優れたCSLAにリファクタリングすると、ドミノ効果が大きくなります。したがって、その最初の注入の後、CSLAは本質的に放棄されます。

編集を終了

于 2012-06-06T21:12:09.113 に答える
13

CSLAは、データ層の上にビジネスオブジェクトを簡単に作成できるビジネスオブジェクトフレームワークです。これにより、堅実なオブジェクト指向のプリンシパルと関心の分離を使用してアプリケーションを設計できます。

Expert C＃2008BusinessObjectsと呼ばれるRockyLhotkaによるCSLAの本を読むことを強くお勧めします。これは、フレームワークについて教えるだけでなく、優れたソフトウェアアーキテクチャの原則についても教えてくれます。

あなたはここアマゾンで本をつかむことができます

于 2009-08-06T04:54:56.290 に答える
6

CSLAとは何ですか？を読むことをお勧めします。ページをクリックし、CSLA.NETFAQサイトを参照します。

最新の公開情報については、CSLA4電子ブックシリーズの使用を確認してください。

于 2013-02-11T06:56:21.030 に答える
6

@radarbob https://stackoverflow.com/a/10922373/261363への返信として、これを後悔せずに炎上戦争を開始することを願っています。

私たちのチームは、CSLAを使用していくつかのLOBアプリケーションを開発してきました。CSLAを使用してグリーンフィールドアプリを作成し、既存のコードを維持した経験から、ここにあなたのポイントに対する私の回答があります。

  1. BOは、独自のデータ永続性を実行することを想定していません。たとえば、ORMを使用して後で保存されるモデルにマップするなど、すべてのデータ永続性を処理するファクトリがあります。

  2. 申し訳ありませんが、既存のコードデータベースにコミットする前に、フレームワークのドキュメントを調べて、少なくとも1つのおもちゃのアプリケーションを作成するようにしています。さらに、CSLAコードをダウンロードして参照することもできます。

  3. BO->ポータル->ファクトリはそれほど複雑ではないはずですが、既存のCSLAの例は、各レベルで何が起こっているかを説明するのに大いに役立ちます。

  4. CLSAをORMと混同しないでください

  5. 当然のことながら、ビジネスオブジェクトが1つのテーブルにマップされることはめったにないため、保存するときに少し作業が必要になります。それらが1つのテーブルにマップされている場合は、AutoMapperなどを使用してBOをPOCOに1行でマップします。

  6. CSLAコマンドを調べてください。また、BOが永続化するPOCOと同じではないことを念頭に置いている限り、BOを必要なだけ小さくまたは大きく保つことを妨げるものではありません。

プロジェクトでは、BOを簡単にテストして、ビジネスロジックが正しいことを確認できるようにしました。関心の分離がうまく行われているため、ファクトリを分離してテストし、ビジネスオブジェクトがそれに応じて永続化されることを確認しました。

ある時点で、BOの一部をMongoDBに簡単に永続化できたため、ビジネスオブジェクトのコードを1行も変更することなく、アプリケーションがハイブリッドデータベースMSSQLとMongoDBで実行されていました。必要なのは、現在のORMの代わりにMongoを使用する工場。

これがあなたのすべてのポイントに公正に対処することを願っています、

よろしく

于 2013-12-20T05:08:49.367 に答える
2

CSLA：コンポーネントベースのスケーラブルな論理アーキテクチャ

ウェブサイトから私にCSLAを説明した一言で言えば、これは次のとおりです。

CSLA .NETを使用すると、ビジネスロジックとデータを抽象化してカプセル化するオブジェクト指向のビジネスレイヤーを作成できます。このフレームワークにより、ビジネスオブジェクトは、WinRT XAML、WPF、ASP.NET MVC、ASP.NET Webフォーム、WCF、asmxサービス、Windows Phone 7、Silverlight、Windowsワークフロー、Windowsフォームなどのすべての.NETインターフェイステクノロジとシームレスに連携します。

なぜそれを使うのか：

ビジネスルール管理。ビジネスルールシステムを学ぶと、きちんとしたパッケージでビジネスロジックを適用する方法が提供されます。検証を親レベルに最も多く報告する必要がある子オブジェクトを持つオブジェクトがある場合、それを処理する方法があります。（ルールシステムの詳細については、http：//www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspxを参照してください）

Nレベルの取り消しをサポートするために必要なビジネスオブジェクトがありますか？CSLA BusinessBaseには、Nレベルの元に戻す（実際には完全に実装されています）などの機能のためのプロパティ管理システム（依存関係プロパティなど）が組み込まれています（これはビジネスルール管理にも関連しています。プライマリプロパティが変更されたときに検証を実行できます。または、別のプロパティの値に基づいてプロパティを変更できます。）

データポータル管理。これは面白いコンセプトでした。データ操作をローカルで実行する必要がある場合、CSLAはすぐに使用できるように構成されています。また、ビジネスオブジェクトライブラリを参照するWCFサービスを立ち上げ、数行の構成を使用して、データ操作を管理するWCFエンドポイントを作成することもできます。WCFサービスは、CSLAフレームワークの一部です。これが実際に動作しているのを見るのは素晴らしかった。他のシナリオ？もちろん！ビジネス・オブジェクト・ライブラリーを変更する必要はありません。DataPortalクラスは、構成に応じて、リモートで実行する必要があるかローカルで実行する必要があるかを判別します。

CSLAは、最初は自然に感じられないかもしれないいくつかのメカニズムを使用することを強制します。これは、実装することを選択したどのパターンにもある程度当てはまると思います。ただし、サービス指向アーキテクチャーの実装の課題に関しては、CSLAは多くのことを提供します。はい、アーキテクトレベルの開発者がライブラリの一部を作成することになります。ただし、エンタープライズクラスのアプリケーションを構築している場合は、すでにそれを行っているべきではありませんか？

CSLAは、正しく設計されていれば、テスト可能です。リポジトリパターンを使用して、実際のdalをモックレイヤーに置き換え、仕様（NUnit / SpecFlowを使用）と、必要に応じてユニット方式の両方でテストします。

Rocky自身を含むサポートに関しては、CSLA.NetforXamarinのようなものが現実になることを保証する貢献者のコミュニティがあります。CSLAを知っていて、仕事の範囲に応じて定期的に使用しているコンサルタントがあります（いいえ、私が働いているコンサルタントだけではありません）。

すべてを考慮すると、CSLAはあなたに適していない可能性があります。他の人が示しているように、サイトと本（特に、Expert C＃2008 Business Objects）を読んでください。CSLAコミュニティは質の高いアドバイスを提供する傾向があるため、質問をしてください。

于 2013-10-03T17:54:24.153 に答える
1

CSLAについて詳しくは、こちらをご覧ください。新しい本は素晴らしい出発点です。この本への素晴らしい賛辞として、 CSLA3.8テンプレートをチェックすることをお勧めします。Rockyは、コードジェネレーターを使用することをお勧めします。すぐに起動して実行できる、主要なテンプレートセットがあります。

ありがとう-BlakeNiemyjski（CodeSmith CSLAテンプレートの作成者）

于 2010-02-01T18:20:07.480 に答える