CSLA を実際に経験した人はいますか?

https://stackoverflow.com/questions/15241

08-06-2019
|

質問

私の会社の主要な Web アプリケーションは、何らかの方法で保守可能でスケーラブルにするための気の利いたライブラリのセットを切望しており、同僚の 1 人が CSLA を提案しました。それで私は本を購入しましたが、次のようになります。

プログラマーはもう本を読まない

SOFlow コミュニティのそれに対する意見を測りたかったのです。

そこで私の質問は次のとおりです。

人々はどのように CSLA を使用しているでしょうか?
長所と短所は何ですか?
CSLA は本当に TDD に適合しないのでしょうか?
私の代替案は何ですか?
使用を中止した場合、または使用をやめた場合、その理由は何ですか?

解決

あなたの質問に具体的に答える前に、いくつかの考えを書き留めておきたいと思います。CSLA はあなたのプロジェクトに適していますか?場合によります。私は個人的に、単体テストを最優先事項として重視しないデスクトップベースのアプリケーションには CSLA を検討します。CSLA は、n 層アプリケーションに簡単に拡張したい場合に最適です。CSLA は純粋な単体テストを許可していないため、批判を受ける傾向があります。これは真実ですが、テクノロジーのあらゆる分野と同様に、 唯一の真の道はない. 。単体テストは、特定のプロジェクトのために行っているものではないかもしれません。あるチームやプロジェクトで機能するものは、別のチームや他のプロジェクトでは機能しない可能性があります。

CSLA に関しては多くの誤解もあります。ORMではありません。これは NHibernate の競合相手ではありません (実際、データアクセスとして CLSA Business Objects と NHibernate を使用すると非常にうまく適合します)。という概念を形式化したものです。 移動体.

1.CSLA を使用している人は何人いますか?
に基づく CSLA フォーラム, CSLAベースのプロジェクトはかなりたくさんあると思います。正直なところ、実際にどれくらいの人が使っているのかわかりません。私は過去に 2 つのプロジェクトでそれを使用しました。

2.長所と短所は何ですか?
短いリストに要約するのは難しいですが、思い浮かぶ長所と短所をいくつか紹介します。
長所:

新しい開発者をスピードアップするのは簡単です。CSLAの本とサンプルアプリは、スピードを上げるための優れたリソースです。
検証フレームワークは真に世界クラスであり、他の多くの非 CSLA プロジェクトやテクノロジーに「借用」されています。
ビジネスオブジェクト内のnレベルの取り消し
n 層スケーラビリティのための構成行の変更 (注:再コンパイルさえ必要ありません）
主要なテクノロジーは「実際の」コードから抽象化されます。WCFが導入されたとき、CSLAコードへの影響は最小限でした。
ビジネスオブジェクトを Windows プロジェクトと Web プロジェクト間で共有することができます。
CSLAは、行動の正規化ではなく、 データ (データ正規化のためにデータベースを残します)。

短所:

単体テストの難しさ
関心事の分離の欠如 (通常、ビジネスオブジェクトの内部にはデータアクセスコードが含まれています)。
CSLA が正常化を推進する中、行動, の正規化ではなく、 データ, その結果、名前は似ていても目的が異なるビジネスオブジェクトが作成される可能性があります。これにより、混乱が生じたり、オブジェクトを適切に再利用できていないような感覚が生じたりする可能性があります。とはいえ、一度生理学的飛躍を遂げると、それは十分に理にかなっています。オブジェクトを「古い」方法で構造化するのは不適切であるように思えます。
この方法でアプリケーションを構築するのは「流行」ではありません。そのテクノロジーに情熱を持った開発者を獲得するのに苦労するかもしれません。

3.これを読んだ後、CSLA は本当に TDD に適合しないのでしょうか?
CSLA で TDD を実行する効果的な方法が見つかりません。そうは言っても、私よりも賢明で、これを試みてより大きな成功を収めた人がたくさんいると確信しています。

4.私の代替案は何ですか?
現在、ドメイン駆動設計が大きく推進されています (当然のことですが、一部のアプリケーションにとっては素晴らしいことです)。LINQ (および LINQ to SQL、Entity Framework など) の導入から発展している興味深いパターンも多数あります。ファウラーの本 PoEAA, では、アプリケーションに適した多くのパターンについて詳しく説明します。いくつかのパターンが競合していることに注意してください（つまり、Active Record と Repository)、したがって、特定のシナリオで使用することを目的としています。CSLA は、その本で説明されているパターンのいずれにも正確には一致しませんが、Active Record に最もよく似ています (ただし、このパターンに完全に一致すると主張するのは短絡的だと私は感じます)。

5.使用を中止した場合、または使用をやめた場合、その理由は何ですか?
前回のプロジェクトでは CSLA を完全には推奨しませんでした。CSLA が提供する利点に対してアプリケーションの範囲が大きすぎると考えたからです。
私は...するだろうない Web プロジェクトで CSLA を使用します。その環境でアプリケーションを構築するのに適したテクノロジーは他にもあると思います。

要約すると、CSLA は単なるものではありませんが、 特効薬, 、いくつかのシナリオに適しています。

お役に立てれば！

他のヒント

すべての回答を読んだ後、かなり多くの人が CSLA について誤解を持っていることに気づきました。

初め、 CSLA は ORM ではありません. 。どうしてそんなにはっきりと言えるのでしょうか？なぜなら、ロックフォード・ロトカ氏自身が、インタビューで何度もそう述べているからだ。 .NETロックス そして ヘンゼルミニッツ ポッドキャスト。探す どれでも ロッキーがインタビューされたエピソードで、彼はそれを明確な言葉で述べます。これは人々が理解すべき最も重要な事実だと思います。CSLA に関するほとんどすべての誤解は、CSLA が ORM であると信じているか、ORM として使用しようとしていることから生じているからです。

Brad Leach 氏が回答でほのめかしたように、CSLA オブジェクトは動作をモデル化しますが、データはオブジェクトにとって不可欠であるため、データの動作をモデル化すると言ったほうが正確かもしれません。CSLA は、データストアとの通信方法に完全に依存しないため、ORM ではありません。あなた すべき CSLA で何らかのデータアクセス層を使用し、場合によっては ORM も使用します。（私はします。現在は Entity Framework を使用していますが、これは美しく機能します。)

さて、単体テストに移ります。データアクセスコードをビジネスオブジェクトに直接入れていないため、CSLA オブジェクトの単体テストで苦労したことはありません。代わりに、リポジトリパターンのバリエーションをいくつか使用します。 リポジトリは CSLA によって消費されます。その逆はありません。 単体テスト用に偽のリポジトリを交換し、ローカルデータポータルを使用することで、 ブーム！ それは簡単です。(Entity Framework で POCO の使用が許可されると、これはさらにクリーンになります。)

これらすべては、CSLA が ORM ではないという認識から来ています。ORM を消費する可能性がありますが、それ自体は ORM ではありません。

乾杯。

アップデート

もう少しコメントしておこうと思いました。

CSLA は LINQ to SQL などに比べて冗長であると言う人もいます。しかし、ここではリンゴとオレンジを比較しています。LINQ to SQL は ORM です。CSLA には CSLA にはない機能がいくつかあり、CSLA には統合検証や L2S にはない機能がいくつかあります。 nさまざまなリモートデータポータルを介した -tier の永続性。実際、最後に言いたいのは、 n-層の永続性は、私にとってそれらすべてに優先します。Entity Framework や LINQ to SQL をネット経由で使用したい場合は、WCF のようなものを間に挟む必要があり、作業量と複雑さが大幅に増大します。 多くの CSLAよりも冗長です。(現在、私は WCF、REST、SOA のファンですが、サービスをサードパーティに公開する場合など、本当に必要な場合に使用してください。ほとんどの基幹業務アプリでは、CSLA は実際には必要なく、CSLA の方が良い選択肢です。) 実際、最新バージョンの CSLA では、Rocky は WCFDataPortal, 、私が使用したことがあります。とてもうまくいきます。

私はのファンです固体, 、TDD、およびその他の最新のソフトウェア開発原則を活用し、実用的な場合にはそれらを使用します。しかし、CSLA の利点はそれらの正統派の反対意見の一部を上回ると私は考えています。いずれにせよ、私は CSLA を TDD で非常にうまく (そして簡単に) 機能させることができたので、それは問題ではありません。

はい、私 (ええと、私たち) は、主に Windows フォームアプリケーションのデータバインドされたフォームであるビジネスプロセスロジックをモデル化するために、これを広範囲に使用しました。アプリケーションは取引システムでした。CSLA は、UI のすぐ下のレイヤーに配置されるように設計されています。

標準的な複雑な基幹業務アプリケーションについて考えると、多くのフィールドとそれらのフィールドに対する多くのルール (フィールド間検証ルールを含む) を含むフォームがあり、子オブジェクトを編集するためにモーダルダイアログを呼び出すことができます。このようなダイアログをキャンセルして、前の状態に戻せるようにしたいと考えています。CSLA はこれをサポートします。

欠点は、少し学習曲線があることです。

覚えておくべき重要なことは、CSLA を使用して、 ユーザー 一部のアプリケーションのフォームと対話します。私にとって最も効率的な方法は、CSLA オブジェクトを構築する前に UI を設計し、そのフロー、動作、検証ルールを理解することでした。CSLA オブジェクトで UI デザインを駆動させないでください。

また、CSLA ビジネスオブジェクトをサーバー側で使用して、クライアントから送信されたオブジェクトを検証できることも非常に便利であることがわかりました。

また、Web サービスに対して非同期に検証を実行するメカニズムも組み込まれていました (つまり、カウンターパーティの信用限度範囲をマスターに対してチェックする）。

CSLA は、UI、ビジネスロジック、永続化の間の強力な分離を強制し、それらに対して大量の単体テストを作成しました。UI 設計から駆動しているため、厳密には TDD ではない可能性がありますが、テストできないという意味ではありません。

唯一の現実的な代替手段は独自のモデルやビジネスオブジェクトを作成することですが、すぐに CSLA が提供する機能 (INotifyPropertyChanged、IDataErrorInfo、PushState、PopState など) を実装することになります。

私はあるプロジェクトで CSLA を使用したことがありますが、それはうまく機能し、物事をはるかにシンプルかつすっきりさせました。

チームが独自の異なる個人的なスタイルでビジネスオブジェクトを作成するのではなく、それに基づいて作業するための共通の基準があることを私たちは知っています。

//アンディ

私も数年前にその経験がありました。これは素晴らしいアーキテクチャですが、非常に複雑で、理解したり変更したりするのが難しく、Web ベースのアプリケーションを開発する私たちのほとんどが必ずしも抱えているわけではない問題を解決しています。これは、トランザクションロジックに重点を置き、Windows ベースのアプリケーションとマルチレベルの取り消しを処理するために開発されました。Web アプリケーションはページレベルでリクエストとレスポンスを行うため、それは不適切だという声が聞こえてきそうですが、AJAX スタイルの Web アプリケーションの場合、この議論はそれほど有効ではないかもしれません。

これには非常に奥深いオブジェクトモデルがあり、それを完全に理解するには時間がかかる場合があります。もちろん、数年以内に多くのことが変わる可能性があります。他の最近の意見も聞きたいです。

すべてを考慮すると、これは私の最初のアーキテクチャ選択ではありません。

CSLA を擁護するために、これまでに行われたコメントの多く、特に単体テストに関するコメントには私も同意します...

私の会社では、Windows フォームデータ入力アプリケーションにこれを広範囲に使用し、高い成功を収めました。

これは、私たち自身で作成する時間や専門知識がなかった、すぐに使える機能を提供してくれました。
これにより、すべてのビジネスオブジェクトが標準化され、メンテナンスが容易になり、新しい開発者の学習曲線が短縮されました。

全体として、それが引き起こした問題は、その利点によって十分に補われたと言えます。

アップデート：さらに、Windows フォームアプリにはまだ使用していますが、Web サイトなどの他のアプリケーションで使用する実験の結果、その機能をあまり必要としない場合にはおそらく扱いにくいことが判明したため、現在軽量化を検討しています。これらのシナリオのオプション。

私はCSLAが必須のチームに参加しました。私たちはリモートデータポータルを使用していません。これが、このフレームワークの使用に同意できる唯一の理由です。私は CSLA の考えに同意したことがないので、おそらくそれが問題点しかない理由なのかもしれません、申し訳ありません。

いくつかの問題:

コードと .NET Framework の間に障害物は必要ありません。これが、このフレームワークが私にとってどのように感じられたかです。リストオブジェクトのオプションは限られていましたが、.NET Framework の豊富なリストオブジェクトは無視する必要がありました。

これらの読み取り専用リストがあり、その後読み取り専用でないリストがあったというのはまったくばかげています。したがって、リストに項目を追加する必要がある場合は、リスト全体を再作成する必要があります...本気ですか?

次に、csla はオブジェクトの状態を管理したいと考えていますが、これは問題ありませんが、実際には何も公開されていません。時々、オブジェクトの状態を再度取得するのではなく、手動で変更したいことがあります。これは、csla が私に望んでいることのように思えます。基本的に、csla が直接アクセスすべきではないと考えていたオプションを公開するために、多くのプロパティを作成することになります。

オブジェクトをインスタンス化できないのはなぜですか?結局、オブジェクトをインスタンス化してそれを返す静的メソッドを作成することになります...冗談ですか?

フレームワークのソースコードを確認すると、リフレクションコードが多用されているようです。

csla を使用する理由:

単純な .net フレームワークはあなたには強力すぎます。
開発者が経験不足でパターンの概念を理解できない場合、CSLA ではほぼ全員が同じ認識を持つことができます。
1. コードと .NET Framework の間に障害物は必要ありません...これらのリストオブジェクトで行き詰まっています。

私たちが CSLA を使い始めたのは、CSLA がモデル層に役立つと考えたからです。これはちょっとやりすぎで、すでにライブラリにリンクされているという理由だけで、現在使用しているのはほとんど SmartDate クラスだけです。

検証インターフェイスはビジネスルールの適用に非常に役立つと考えましたが、WCF とシリアル化ではうまく機能しませんでした (バージョン 2.0.3.0 のままなので、状況は変わっている可能性があります)。

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 オブジェクトは自立しています。彼らは自分のデータを取得し、自分の行動を管理し、自分自身を救います。残念ながら、これは、平均的な CSLA オブジェクトには少なくとも 3 つの役割があることを意味します。つまり、ドメインモデルを表すこと、ビジネスルールを含むこと、データアクセス定義 (前に述べ/暗示したように、DAL またはデータアクセス実装ではありません) を含むことです。時間。

私たちは CSLA を広く使用しています。いくつかの利点があります。まず、あらゆる分野の開発者は Business Objects プログラミングに関する Rocky Lhotka の本を読むべきだと私は信じています。個人的には、これまでのプログラミング本のベスト 3 に入る本だと思います。CSLA はこの本に基づいたフレームワークであり、これを使用すると、プロジェクトで n レベルの取り消し、検証ルール、スケーラビリティアーキテクチャなどの非常に高度な機能にアクセスできるようになり、詳細が提供されます。「隠す」ではなく「提供する」と言ったことに注意してください。CSLA の最も優れている点は、これらすべてが自分で再現しなくても、ソースコードに至るまでどのように実装されているかを理解できることであることがわかりました。必要なだけ多くの機能を使用するか、または少ない機能を使用するかを選択できますが、フレームワークの設計パターンに忠実であれば、問題を回避できることがわかりました。--バイロン

私たちは 5 年以上 CSLA を使用していますが、ビジネスアプリケーションの構築には非常にうまく機能すると考えています。コード生成と組み合わせると、比較的短い時間でビジネスオブジェクトを作成し、作業に集中できます。肉アプリケーションの。

私は vb5 から CSLA を使用していますが、当時は CSLA はフレームワークというよりもパターンのコレクションでした。.NET の導入により、CSLA は多大な学習曲線を伴う本格的なフレームワークになりました。ただし、CSLA は、すべてのビジネス開発者がある時点で (プロジェクトの範囲に応じて) 自分で作成する傾向がある多くの事項に対処しています。検証ロジック、認証ロジック、元に戻す機能、ダーティロジックなど。これらすべては、1 つの優れたフレームワークですぐに無料で入手できます。

他の人が述べているように、フレームワークであるため、開発者は同様の方法でビジネスロジックを作成する必要があります。また、ビジネスロジックに一定レベルの抽象化を提供する必要があるため、MVC、MVP、MVVM などの UI フレームワークを使用しないことがそれほど重要ではなくなります。

実際、これらの UI パターンの多くが今日 (Microsoft の世界で) 非常に誇大宣伝されている理由は、人々が信じられないほど間違ったことを長い間行ってきたからだと私は主張します (つまり、UI で DataGrids を使用したり、散りばめたり)ビジネスロジックをどこにでも配置できます。チスクチスク）。中間層 (ビジネスロジック) を最初から正しく設計すると、どの 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 を初めて使用しますが、概念は理解していますし、CSLA が ORM ツールではないこともすでに理解しているので、ドラムを叩くのはやめてください。CSLA には気に入っている機能がありますが、それらを使用すると、カーテンの後ろに魔術師がいるような気分になります。それがどのように機能するか知らなくても構わないのであれば、オブジェクトを使用しても問題なく動作すると思います。

初心者にとっては学習に時間がかかるので、5 ～ 15 分あれば大きなメリットがあると思います。Microsoft のような基礎を学ぶためのビデオ。あるいは、コードをリリースして本を発売するまでに何か月もかかるのではなく、コードを含む関連書籍をリリースするのはどうでしょうか?ロトカさんって言ってるだけで…私たちは本が出版される前に作品を作り始めましたが、その間ずっと苦労していました。しかし、先ほども言いましたが、私はそれが初めてです。

CSLAを使用しました。オブジェクトを型に合わせて作成し、フレームワークが提供するものの 10% を使用しました。オブジェクトレベルで元に戻す？使いませんでした。NT レベルの柔軟性?使いませんでした。結局、CSLA から得られるのは複雑さだけだと思うほどのビジネスルールコードを作成することになりました。このフレームワークを知っている一部の「歯がゆい」開発者は、打つ必要がある釘を持っていたため、フレームワークをハンマーとして使用していました。CSLA は彼らの一員でしたし、私の推測では、この枠組みの支持者の多くもその観点から物事を見ているのではないかと思います。

経験豊富な開発者は、すべてが理にかなっているので満足していると思います。あなたの組織に初心者プログラマーがおらず、整ったパターンで効率的でシンプルな POCO オブジェクトを書くのに飽きてしまっているのであれば、そうすればいいでしょう。CSLA を使用します。

私は中規模プロジェクトのビジネスオブジェクトフレームワークとして CSLA を使用しています。このフレームワークは VB6 の時代から大きく進化しており、並外れた柔軟性と「すぐに使える」機能を提供します。CSLA のモバイルスマートオブジェクトにより、UI 開発がはるかに簡単になります。ただし、私は他の人にも同意します。これはあらゆる状況に適したツールではありません。確かにある程度のオーバーヘッドが関係しますが、多くの電力も必要になります。個人的には、Silverlight で CSLA Light を使用することを楽しみにしています。

長所:

データテクノロジーに依存しない¹
大規模なインストールベースは無料です!!
安定した論理的なフレームワーク
データアクセスコードはオブジェクトまたは別のアセンブリに含めることができます
プロパティとオブジェクトの検証と認可

短所

コードのメンテナンスが多くなる場合がある²
おそらく効果的に使用するにはコードジェネレーターが必要です
学習曲線。CSLA オブジェクトの構造は把握しやすいですが、注意点があると頭痛の種になる可能性があります。

テスト駆動設計についてはよくわかりません。私は単体テストやテスト駆動設計をしないので (恥ずかしいのですが)、単体テストが TDD と異なるかどうかはわかりませんが、フレームワークの最新バージョンには単体テストが付属していることは知っています。

¹ データアクセステクノロジは長期間同じ状態にならないため、これは良いことです。
² これは、フレームワークの最近のバージョンでは改善されています。

多くの人が CSLA でコード生成を使用することを推奨しています。ROI が大幅に向上するため、サポートされているテンプレートのセットをチェックすることをお勧めします。

ありがとう - ブレイクniemyjski（Theの著者 CodeSmith CSLA テンプレート)

数年前にプロジェクトで使用しました。しかし、プロジェクトが完了したとき、CSLA が私に何をしてくれたのかを誰にも話すことができませんでした。確かに、そのクラスから継承しました。しかし、再構築することなく、ほぼすべてのクラスからその継承を削除することができました。N 層のものは使い道がありませんでした。n レベルのアンドゥは非常に遅いため、使用できませんでした。したがって、最終的にはクラスをモデル化するのに役立つだけだったと思います。

そうは言っても、（独自のフレームワークを作成するというチームによる恐ろしい試みの後）他のチームもそれを使い始めています。彼らは皆私よりも賢いので、そこには何か価値のあるものがあるはずです。

私はPHP派です。PHP を使用して比較的大規模なアプリケーションを構築し始めたとき、私は基本的に PHP の世界で、次に Java と .NET で多くのアプリケーションフレームワークと ORM について研究を始めました。Java および .NET フレームワークにも注目した理由は、PHP フレームワークを盲目的に使用することではなく、まず実際に何が起こっているのか、どのような種類のエンタープライズレベルのアーキテクチャがあるのかを理解しようとするためでした。

私は実際のアプリケーションで CSLA を使用したことがないので、その長所と短所についてコメントすることはできませんが、私が言えることは、Lhotka はソフトウェアアーキテクチャの分野における稀有な思想家 (単なる専門家とは言いません) の 1 人であるということです。ドメイン駆動設計という名前はエリック・エヴァンスによって造られたものですが、彼の本も素晴らしいのでぜひ読むことをお勧めしますが、ロトカは何年にもわたってドメイン駆動設計を適用していました。そうは言っても、彼のフレームワークについてどう考えても、この分野における彼の深いアイデアから恩恵を受けることができます。

彼の講演は dotnetrocks.com/archives.aspx で、ビデオは dnrtv.com/archives.aspx (Lhotka で検索) でご覧いただけます。

@byronあなたが気に入った他の2冊の本は何ですか？

ジョン、

私たちは CSLA 2 から 3.5 までのチームで作業していますが、すべての開発者が「同じ方法で作業する」ように一貫したフレームワークを提供するのに優れた方法であることがわかりました。価値の低いコードのほとんどが生成され、単体テストを実行すると、すべての CRUD 要素に対してすぐに機能することがわかります。私たちの TDD は、設計のために行うリファクタリングに実際に組み込まれていることがわかりました。CSLA は、それを行うことを妨げるものではありません。

クリス

私が最後に CSLA を使用しようとしたのは、石器時代の VB6 の時代でした。今にして思えば、コード生成を使用していればもっと効果的だったと思います。効果的なコード生成ツールとそれをワークフローに適合させるための戦略がない場合は、CSLA などのフレームワークを避ける必要があります。そうしないと、CSLA から得られる機能が n 行の記述に費やした時間を補うことができなくなります。テーブルあたりのコード数、列あたりのコード n 行など。

私はこれまでいくつかのプロジェクトで CSLA.NET を使用してきましたが、(asp.net アプリケーションにはない) 豊富なデータバインディング互換性を持つ Windows フォームアプリケーションで最も成功しました。

その主な問題は、人々が指摘しているように、TDD サポートです。これは、Dataportal_XYZ 関数のブラックボックスのような動作が原因であり、データオブジェクトをモックすることができないためです。この問題を回避するための取り組みが行われてきました。これ最良のアプローチであること

私はそれを使いたかったのですが、当時の主任開発者は「魔法」がかかりすぎると考えていました...

CSLA は、現存する最高のアプリケーションフレームワークです。Rocky LHotka はとても賢い男です。彼は Martin Fowler や David S Platt のようにソフトウェア開発の歴史を書いていますが、私のお気に入りの作家は、Rod Stephens、Mathew mcDonalds、Jeff Levinson、thearon Willis、Louis Davidson 別名 dr sql です。:-) Pro：すべてのデザインパターンが適用されます。短所:学習するのが難しく、サンプルが少ない。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow