私の会社の主要な Web アプリケーションは、何らかの方法で保守可能でスケーラブルにするために、気の利いた一連のライブラリを切望しており、私の同僚の 1 人が CSLA を提案しました。だから私は本を買ったが、次のように：
プログラマーはもう本を読まない
SOFlow コミュニティの意見を評価したかったのです。
だからここに私の質問があります：
あなたの質問に具体的に答える前に、いくつかの考えを書き留めておきたいと思います。CSLA はあなたのプロジェクトに適していますか? 場合によります。個人的には、単体テストを重視しないデスクトップ ベースのアプリケーション向けの CSLA を最優先事項と考えています。CSLA は、n 層アプリケーションに簡単にスケーリングしたい場合に最適です。CSLA は、純粋な単体テストを許可していないため、不満を抱く傾向があります。これは真実ですが、テクノロジーのあらゆる分野と同様に、唯一無二の真の道はないと私は信じています。単体テストは、特定のプロジェクトのために行っているものではない場合があります。あるチームと 1 つのプロジェクトでうまくいくことは、別のチームや他のプロジェクトではうまくいかないかもしれません。
CSLA に関しても多くの誤解があります。ORM ではありません。NHibernate の競合相手ではありません (実際、CLSA Business Objects と NHibernate をデータ アクセスとして使用すると、非常にうまく適合します)。Mobile Objectの概念を形式化します。
1. CSLA を使用している人は何人ですか? CSLA フォーラム
に
基づくと、CSLA ベースのプロジェクトはかなりの数あると思います。正直なところ、実際にどれだけの人が使っているかわかりません。過去に2つのプロジェクトで使用しました。
2. 長所と短所は何ですか?
短いリストに要約するのは難しいですが、思いつく賛否両論のいくつかを以下に示します。
長所：
短所：
3. これを読んだ後、CSLA は本当に TDD に適合しないのでしょうか?
CSLA で TDD を行う効果的な方法が見つかりませんでした。とはいえ、これを試して大きな成功を収めたかもしれない私よりも賢い人がたくさんいると確信しています.
4. 私の代替手段は何ですか?
現在、ドメイン駆動設計が大きく推進されています (当然のことながら、一部のアプリケーションにとっては素晴らしいことです)。LINQ (および LINQ to SQL、Entity Framework など) の導入から発展した興味深いパターンも多数あります。Fowlers book PoEAAでは、アプリケーションに適した多くのパターンについて詳しく説明しています。一部のパターンは競合しているため (アクティブ レコードとリポジトリなど)、特定のシナリオで使用することを意図していることに注意してください。CSLA は、その本で説明されているどのパターンとも完全には一致しませんが、Active Record に最もよく似ています (ただし、このパターンと完全に一致すると主張するのは短絡的だと思います)。
5. 使用をやめた場合、または使用しないことに決めた場合は、その理由を教えてください。
前回のプロジェクトでは、CSLA を完全には推奨しませんでした。なぜなら、アプリケーションの範囲が CSLA が提供する利点に対して大きすぎると思うからです。Web プロジェクトでは CSLA を使用し
ません。その環境でアプリケーションを構築するのにより適した他のテクノロジがあると思います。
要約すると、CSLA は特効薬ではありませんが、一部のシナリオには適しています。
お役に立てれば！
すべての回答を読んだ後、かなりの数の人々が CSLA について誤解していることに気付きました。
まず、CSLA は ORM ではありません。どうしてそう断言できるの？Rockford Lhotka が.NET RocksおよびHanselminutesポッドキャストのインタビューで何度も述べているからです。ロッキーがインタビューされたエピソードを探してみてください。CSLA に関するほとんどすべての誤解は、それが ORM であると信じたり、ORM として使用しようとしたりすることから生じるため、これは人々が理解すべき最も重要な事実だと思います。
Brad Leach が回答で言及したように、CSLA オブジェクトは動作をモデル化しますが、データはデータの動作をモデル化すると言ったほうが正確かもしれません。CSLA は ORM ではありません。これは、データ ストアとの通信方法に完全に依存しないためです。CSLA では何らかのデータ アクセス レイヤーを使用する必要があります。おそらく ORM も使用する必要があります。(そうです。私は今、美しく機能する Entity Framework を使用しています。)
では、単体テストに進みます。データ アクセス コードをビジネス オブジェクトに直接入れていないため、CSLA オブジェクトのユニット テストで問題が発生したことはありません。代わりに、リポジトリ パターンのいくつかのバリエーションを使用します。リポジトリは CSLA によって消費されますが、その逆ではありません。単体テスト用に偽のリポジトリを交換し、ローカル データ ポータルのBOOM!を使用します。それは簡単です。(Entity Framework で POCO の使用が許可されると、これはさらにクリーンになります。)
これはすべて、CSLA が ORM ではないことを認識することから来ています。それは ORM を消費するかもしれませんが、それ自体は ORM ではありません。
乾杯。
もう少しコメントを書こうと思いました。
CSLA は LINQ to SQL などに比べて冗長であると言う人もいます。しかし、ここではリンゴとオレンジを比較しています。LINQ to SQL は ORM です。CSLA が提供していないものと、L2S が提供していないものがいくつかあります。たとえば、統合された検証や、さまざまなリモート データ ポータルを介したn層の永続性などです。実際、最後の要素であるn層の永続性は、私にとってはそれらすべてに勝ると言えます。ネット上で Entity Framework や LINQ to SQL を使用したい場合は、間に WCF のようなものを配置する必要があり、それによって作業と複雑さが大幅に増大し、かなりの負担になると思います。CSLA よりも詳細です。(現在、私は WCF、REST、および SOA のファンですが、サービスをサード パーティに公開する場合など、本当に必要な場合に使用します。ほとんどの基幹業務アプリでは、そうではありません。実際、CSLA の最新バージョンでは、Rocky が を提供しておりWCFDataPortal、私はこれを使用しました。それはうまくいきます。
私はSOLID、TDD、およびその他の最新のソフトウェア開発原則のファンであり、実用的な場所ならどこでもそれらを使用しています。しかし、CSLA の利点は、これらの正統派の反論のいくつかを上回っていると思います。いずれにせよ、CSLA を TDD でうまく (そして簡単に) 動作させることができたので、それは問題ではありません。
はい、私 (ええと、私たち) は、主に Windows フォーム アプリケーションのデータバインドされたフォームであるビジネス プロセス ロジックをモデル化するために、これを広範囲に使用しました。アプリケーションは取引システムでした。CSLA は、UI のすぐ下のレイヤーに配置されるように設計されています。
標準の複雑な基幹業務アプリケーションについて考えてみると、多くのフィールド、それらのフィールドに対する多くのルール (クロスフィールド検証ルールを含む) を持つフォームがあり、モーダル ダイアログを呼び出していくつかの子オブジェクトを編集したり、このようなダイアログをキャンセルして、以前の状態に戻すことができるようにしたいと考えています。CSLA はこれをサポートします。
短所は、学習曲線が少しあることです。
覚えておくべき重要なことは、CSLA を使用して、ユーザーがアプリケーションのフォームと対話する方法をモデル化することです。私にとって最も効率的な方法は、CSLA オブジェクトを構築する前に、UI を設計し、そのフロー、動作、および検証ルールを理解することでした。CSLA オブジェクトで UI デザインを動かさないでください。
また、CSLA ビジネス オブジェクトのサーバー側を使用して、クライアントから送信されたオブジェクトを検証できることも非常に便利であることがわかりました。
また、Web サービスに対して非同期で検証を実行するメカニズムも組み込みました (つまり、カウンターパーティの与信限度範囲をマスターに対してチェックします)。
CSLA は、UI、BusinessLogic、および Persistance 間の強力な分離を強制し、それらに対する多数の単体テストを作成しました。UIデザインから推進しているため、厳密にはTDDではないかもしれませんが、それはテスト可能ではないという意味ではありません。
唯一の現実的な代替手段は、独自のモデルやビジネス オブジェクトを作成することですが、すぐに CSLA がすぐに提供する機能 (INotifyPropertyChanged、IDataErrorInfo、PushState、PopState など) を実装することになります。
私は 1 つのプロジェクトで CSLA を使用しましたが、これはうまく機能し、物事をよりシンプルできれいにしました。
チームが独自の異なる個人的なスタイルでビジネス オブジェクトを作成するのではなく、反対する共通の基準があることを私たちは知っています。
//アンディ
私は数年前にそれを経験しました。これは素晴らしいアーキテクチャですが、非常に複雑で、理解や変更が難しく、Web ベースのアプリケーションを開発しているほとんどの人が必ずしも抱えていない問題を解決しています。これは、トランザクション ロジックに重点を置いて、Windows ベースのアプリケーションと複数レベルの取り消しを処理するために開発されました。Web アプリケーションはページ レベルでの要求と応答であるため、不適切であると言う人がいるかもしれませんが、AJAX スタイルの Web アプリケーションでは、この議論はそれほど多くの根拠を持たないかもしれません。
これには非常に深いオブジェクト モデルがあり、頭で理解するには時間がかかる場合があります。もちろん、数年で多くのことが変わる可能性があります。他の最近の意見を聞きたいです。
すべてを考慮すると、それは私の最初のアーキテクチャ選択ではありません。
CSLAを擁護するために、特にユニットテストで行われたコメントの多くに同意しますが...
私の会社は、Windowsフォームデータ入力アプリケーションに広く使用しており、高い成功を収めています。
全体として、それが引き起こした問題は、利益によって解決された以上のものだったと思います。
更新：これに加えて、Windowsフォームアプリでも使用していますが、Webサイトなどの他のアプリケーションで使用した実験では、その機能の多くを必要としない場合はおそらく面倒であることが示され、現在調査中です。これらのシナリオの軽量オプション。
リストのCSLAを取るのではなく、それを使用する前に、利点を調査し、それらが実際に適用されることを確認してください。あなたのチームはそれを正しく/一貫して実装することができますか？リモーティングとポータルダンスが必要ですか？
私はすべての理論的な熟考を超えて、それは基本的な証明されたパターンに従ったクリーン/メンテナンス可能/拡張可能/テスト可能なコードに関するものだと思います。
CSLAから変換されたプロジェクトの特定のドメインで必要なコードの行数を数えました。すべての異なるCSLAオブジェクト（読み取り専用+編集可能+ルート+リストの組み合わせ）とそれらのストアドプロシージャの間では、約1700行かかりましたが、Linq2SQL+リポジトリの実装では180行かかりました。Linq2SQLバージョンは、ほとんどの場合、チームが理解するために本を消費する必要のない生成されたクラスで構成されていました。はい、CodeSmithを使用してCSLAパーツを生成しましたが、単一責任ビットを使用したDRYコードを信じており、CSLAの実装は昨日のヒーローのように見えます。
別の方法として、Linq2Sql / Entity Framework/NHibernateをRepositoryおよびUnitOfWorkパターンと組み合わせて調べることをお勧めします。http://www.codeplex.com/backgroundmotionをご覧ください
乾杯！
当社はいくつかのプロジェクトで CSLA を実践しており、レガシー プロジェクトのいくつかは CSLA のままです。CSLA が明確で単純な OOP ルールである単一責任の原則に違反したため、他のプロジェクトはそれから離れました。
CSLA オブジェクトは自立しています。たとえば、独自のデータを取得し、独自の動作を管理し、保存します。残念ながら、これは、平均的な CSLA オブジェクトには少なくとも 3 つの責任があることを意味します。つまり、ドメイン モデルを表し、ビジネス ルールを含み、データ アクセス定義を含みます (以前に述べた/暗示したように、DAL やデータ アクセスの実装ではありません)。時間。
モデルレイヤーに役立つと思ったので、CSLA を使い始めました。ちょっとやり過ぎで、ライブラリにすでにリンクされているという理由だけで、現在使用しているのは SmartDate クラスだけです。
検証インターフェイスはビジネス ルールの適用に非常に役立つと考えていましたが、WCF とシリアル化ではうまく機能しませんでした (まだバージョン 2.0.3.0 にとどまっているため、変更されている可能性があります)。
私たちはCSLAを広く使用しています。いくつかの利点があります。まず、すべての事業部門の開発者は、Business Objects プログラミングに関する Rocky Lhotka の本を読むべきだと思います。個人的には、これまでで最高のプログラミング本のトップ 3 に入っていることがわかりました。CSLA はこの本に基づいたフレームワークであり、これを使用すると、詳細を提供しながら、プロジェクトで n レベルの取り消し、検証ルール、スケーラビリティ アーキテクチャなどの非常に高レベルの機能にアクセスできます。「隠す」ではなく「提供する」と言ったことに注意してください。CSLA の最も優れた点は、これらすべてがどのようにソース コードに実装されているかを、自分で再現しなくても理解できることです。必要に応じて多くの機能を使用するか、少数の機能を使用するかを選択できますが、フレームワークの設計パターンに忠実であり続けることで、それは本当にあなたをトラブルから守ります。--バイロン
私は CSLA を初めて使用しますが、概念は理解していますし、それが ORM ツールではないことも既に理解しています。私が気に入っている CSLA の機能もありますが、それらを使用すると、カーテンの後ろに魔法使いがいるような気がします。それがどのように機能するかを知らなくても構わないのであれば、オブジェクトを使用でき、それらは正常に機能すると思います。
初心者には大きな学習曲線があり、5 ～ 15 分あれば大きなメリットがあると思います。Microsoft のような基本を学ぶためのビデオ。または、コードをリリースして本を出すのに何ヶ月もかかるのではなく、コード付きのコンパニオン ブックをリリースするのはどうですか? Lohtka氏とだけ言っておきます... 私たちは本の前に自分たちのものを作り始めました、そして私はずっと苦労しました. しかし、私が言ったように、私はそれに慣れていません。
CSLAを使用しました。オブジェクトを型に合わせて作成し、フレームワークが提供するものの 10% を使用しました。オブジェクト レベルで取り消しますか? 使用しませんでした。N層の柔軟性？使用しませんでした。最終的に十分なビジネス ルール コードを作成したため、CSLA から得られるのは複雑さだけだと思いました。フレームワークがハンマーとして使用されていることを知っている「長年の」開発者の中には、打つ必要のある釘があったため、フレームワークをハンマーとして使用した人もいます。CSLAは彼らのベルトであり、フレームワークの多くの支持者もその観点から物事を見ていると思います.
経験豊富な開発者は、すべてが理にかなっているので満足していると思います。組織に新人プログラマーがいない場合や、適切に形成されたパターンを使用して効率的で単純な POCO オブジェクトを作成することに飽き飽きしている場合は、それを試してみてください。CSLA を使用します。
現在、CSLA を 5 年以上使用しており、ビジネス アプリケーションの構築には優れていると考えています。コード生成と組み合わせることで、比較的短い時間でビジネス オブジェクトを作成し、アプリケーションの本質に力を注ぐことができます。
私は CSLA をフレームワークというよりもパターンのコレクションであった vb5 から使用しています。.NET の導入により、CSLA は本格的なフレームワークになりましたが、これには多大な学習曲線が伴いました。ただし、CSLA は、検証ロジック、認証ロジック、元に戻す機能、ダーティ ロジックなど、すべてのビジネス開発者がある時点で (プロジェクトのスコープに応じて) 自分で作成する傾向がある多くの事柄に対応しています。 1 つの素敵なフレームワークのボックス。
他の人が述べているように、フレームワークであるため、開発者は同様の方法でビジネス ロジックを作成する必要があります。また、MVC、MVP、MVVM などの UI フレームワークを使用しないことがそれほど重要でなくなるように、ビジネス ロジックに一定レベルの抽象化を提供する必要があります。
実際、今日 (Microsoft の世界で) これらの UI パターンの多くが非常に盛り上がっている理由は、人々が非常に長い間信じられないほど間違ったことを行ってきたためです (つまり、UI で DataGrid を使用したり、あなたのビジネスロジックをどこにでも.tisk tisk). 最初から中間層 (ビジネス ロジック) を正しく設計すると、任意の UI で中間層を再利用できます。Win フォーム、ASP.NET/MVC、WCF サービス、WPF、Silverlight**、Windows サービス、....
しかし、これらとは別に、私にとって大きな見返りは、組み込みの拡張機能です。CSLA は、構成ファイルを介して構成可能なプロキシ パターンを使用します。これにより、ビジネス オブジェクトはサーバーからサーバーへのリモート呼び出しを行うことができます。コードを 1 リックも書く必要はありません。システムにユーザーを追加しますか? 問題ありません。CSLA ビジネス オブジェクトを新しいアプリケーション サーバーにデプロイし、構成ファイルのエントリを変更して、BAM を実行してください。インスタント スケーラビリティのニーズが満たされます。
これを、DTO を使用し、ビジネス ロジックをクライアント (クライアントが何であれ) に格納し、独自の CRUD メソッドをそれぞれサービス メソッドとして記述する必要がある場合と比較してください。うわぁ！！！これが悪いアプローチだと言っているわけではありませんが、私はそうしたくありません。本質的に私のためにそれを行うためのフレームワークがそこにあるときではありません。
CSLAはORMではないという他の人々の発言を繰り返します。CSLA では、ビジネス オブジェクトにデータを提供する必要があります。彼らはあなたがどこでデータを入手するかを気にしません。ORM を使用して、ビジネス オブジェクトにデータを提供できます。生の ADO.NET、その他のサービス (RESTFUl、SOAP)、Excel スプレッドシートも使用できます。
TDD のサポートについては、CSLA でもそのアプローチを試したことはありません。私は、クラス図とシーケンス図を使用して中間層 (ビジネス オブジェクト) をモデル化するアプローチを採用しており、ほとんどの場合、ユース ケース、画面、および/またはプロセスの設計を指示することができます。少し古めかしいかもしれませんが、UML は私の設計と開発の取り組みにおいて常に非常に役に立ちました。現在も使用されている非常に大規模でスケーラブルなアプリケーションの設計と開発に成功しました。WCF RIA が成熟するまでは、CSLA を使用し続けます。
**いくつかの回避策あり
多くの人が、CSLA でコード生成を使用することを推奨しています。サポートされているテンプレートのセットをチェックすることをお勧めします。ROI が大幅に向上するからです。
ありがとう -Blake Niemyjski ( CodeSmith CSLA テンプレートの作成者)
中規模プロジェクトのビジネス オブジェクト フレームワークとして CSLA を使用しています。このフレームワークは VB6 の時代から大きく進歩しており、並外れた柔軟性と「すぐに使える」機能を提供します。CSLA のモバイル スマート オブジェクトにより、UI 開発がはるかに簡単になります。ただし、すべての状況に適したツールではないという意見にも同意します。多少のオーバーヘッドが伴うことは間違いありませんが、多くの電力も必要です。個人的には、Silverlight で CSLA Light を使用することを楽しみにしています。
1データ アクセス テクノロジは同じ状態が長く続くことはないため、これは良いことです。
2これは、フレームワークの最近のバージョンでは改善されています。
私はPHPの人です。PHPを使用して比較的大規模なアプリケーションを構築し始めたとき、私は基本的にPHPの世界で、次にJavaと.NETで多くのアプリケーションフレームワークとORMの研究を始めました。私がJavaと.NETFrameworkも調べた理由は、PHPフレームワークを盲目的に使用するためではなく、最初に実際に何が起こっているのか、そしてどのようなエンタープライズレベルのアーキテクチャーがあるのかを理解しようとするためです。
私は実際のアプリケーションでCSLAを使用したことがないので、その長所と短所についてコメントすることはできませんが、Lhotkaはソフトウェアアーキテクチャ分野の珍しい思想家の1人です。ドメイン駆動設計という名前はエリック・エバンスによって造られましたが、彼の本も素晴らしく、私はそれを読むことを謙虚に勧めますが、ロトカは何年もの間ドメイン駆動設計を適用していました。そうは言っても、彼のフレームワークについてどのように考えても、この分野での彼の深遠なアイデアから恩恵を受けます。
彼の講演はdotnetrocks.com/archives.aspxで、ビデオはdnrtv.com/archives.aspx（Lhotkaを検索）から見つけることができます。
@Byronあなたが好きだった他の2冊の本は何ですか？
ジョン、
2 から 3.5 までの CSLA で作業しているチームがあり、すべての開発者が「同じように」一貫したフレームワークを提供する優れた方法であることがわかりました。価値の低いコードのほとんどが生成されることは素晴らしいことであり、単体テストを実行すると、すべての CRUD に対してすぐに動作することがわかります。私たちの TDD は、設計のために行うリファクタリングに実際に組み込まれていることがわかりました。CSLA は、私たちがそれを行うことを妨げません。
クリス
私は現在、いくつかのプロジェクトで CSLA.NET を使用しています。これは、豊富なデータバインディングの互換性 (asp.net アプリケーションにはありません) を持つ Windows フォーム アプリケーションで最も成功しました。
主な問題は、人々が指摘しているように TDD のサポートです。これは、Dataportal_XYZ 関数のブラック ボックスのような動作が原因であり、データ オブジェクトをモックすることができないためです。この問題を回避するための取り組みが行われており、これが最善のアプローチです
数年前にプロジェクトで使用しました。しかし、プロジェクトが完了したとき、CSLA が私のために何をしてくれたのか誰にも言えませんでした。確かに、私はそのクラスから継承しました。しかし、再構築することなく、ほとんどすべてのクラスからその継承を削除することができました。N層のものは使い物になりませんでした。n レベルの取り消しは非常に遅く、使用できませんでした。つまり、最終的には、クラスをモデル化するのに役立つだけだったと思います。
そうは言っても、他のチームがそれを使い始めました（チームが独自のフレームワークを作成しようとした恐ろしい試みの後）。彼らはみんな私より賢いので、そこには価値のある何かがなければなりません!
私は最後にVB6の石器時代にCSLAを使おうとしました。振り返ってみると、コード生成を使っていればもっと効果的だったでしょう。効果的なコード生成ツールと、それらをワークフローに適合させるための戦略がない場合は、CSLA のようなフレームワークを避ける必要があります。そうしないと、CSLA から得られる機能が、n 行の記述に費やした時間を補うことはできません。テーブルあたりのコード数、列あたり n 行のコードなど。
私はそれを使いたかったのですが、当時の主任開発者は、あまりにも多くの「魔法」が関係しているという考えを持っていました...
CSLA は、現存する最高のアプリケーション フレームワークです。Rocky LHotka は非常にスマートな男です。彼は Martin Fowler、David S Platt のようなソフトウェア開発の歴史を書いていますが、私のお気に入りの作家は Rod Stephens、Mathew McDonald、Jeff Levinson、thearon willis、Louis Davidson 別名 dr sql です。:-) 長所: すべての設計パターンが適用されます。短所: 習得が難しく、サンプルが少ない。