0

ProjectTracker CSLAのサンプルソリューションを見ていますが、DALのプロジェクト、DALのEF実装、およびビジネスオブジェクト/ルールなどのプロジェクトがあります。

論理的な分離をプロジェクトに分割することは良い習慣だと理解しています。私の懸念を買うのは、DALとEFをビジネスアセンブリに入れることに本当に問題があるのでしょうか。

ビルド時間はプロジェクトの数に最も影響されるようです。

私が取り組んでいるアプリには、例のレイアウトに従った場合、18以上のプロジェクトが含まれる可能性があります。

私はこれを軽減するのに役立つ複数の解決策を作ることができることを知っていますが、私は最初からこの道を進みたくありません。

ありがとう。

4

2 に答える 2

4

複数のプロジェクトが推奨されており、CSLAとそのn層アーキテクチャを最大限に活用するために必要です。

疑いの余地なく、n層の展開、高度なセキュリティ、拡張性の向上が不要であり、一般にエンタープライズレベルのアプリの構築を検討していないことがわかっている場合は、使用するプロジェクトの数を減らすことができます。

実際、2層アプリとしてデプロイすることがわかっているアプリを構築している場合は、ビジネスクラスとデータアクセスクラスをUIコードとともにUIプロジェクトに直接配置できます。

それは良い考えですか？いいえ。

それは機能しますか？はい。

于 2013-03-31T04:12:06.553 に答える
1

Rockyの答えに便乗するために、私が働いている会社はCSLAを使用しており、元々はビジネスクラスにすべてのDALコードがありました。当時はdbmsとしてOracle10gを使用していましたが、SQL Azureに切り替えたいと考えていました（そして、かなり大きなシステムアップグレードとスキーマ変更を同時に行いました）。そこで、次のことを行いました。

  • DALインターフェースをプロジェクトとして実装する
  • 2つのDALプロジェクトを実装します。1つはOracleとSQL用です（実際には3つはモックデータベース付きですが、概念実証のためのものでした）。

これにより、両方のデータベースで同時に変換をテストできます。そもそもDALプロジェクトから始めていたら、これははるかに簡単に達成できたでしょう。

簡単に言えば、もっと時間がかかるかもしれませんが、ロッキーのすべてのポイントに前向きでない限り、それだけの価値があります。

于 2013-06-27T19:10:58.850 に答える