問題タブ [bll]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
architecture - DAL/BLL とクライアント/サーバー: クライアントはプレゼンテーションに BLL オブジェクトまたは DAL オブジェクトを使用する必要がありますか? それとも別のレイヤー(データ転送オブジェクト?)
私はクライアント/サーバーシステムを書いています。サーバーは DAL/BLL 設計です。クライアントは、データ オブジェクトを提示し、ダイアログとウィザードを提供して、ユーザーがこれらのオブジェクトを更新できるようにする (つまり、ユーザーの追加/編集) 必要があります。
最初は、DAL オブジェクトにユニバーサル データ プロバイダー オブジェクトを持たせて、クライアントだけでなくサーバーでも使用できるようにしようと考えていました。たとえば、データ オブジェクトがサーバーによって使用されている場合、データベースがデータ プロバイダーになります。データ オブジェクトがクライアントによって使用されている場合、サーバーがデータ プロバイダーになります。
したがって、オブジェクトはプレゼンテーション レイヤーで変更されます。たとえば、「user」: user->setName("Fred") で、この user->commit() のようにコミットします。commit メソッドはデータ プロバイダーの commit メソッドを呼び出します。次に、オブジェクトをエンコードしてサーバーに送信します。次に、サーバーはそれをビジネス層オブジェクトで「装飾」し、そこから続行します。
私は現在、クライアントとサーバーの両方で使用される共有プロジェクトで定義された DAL オブジェクトを使用して、これをプロトタイプとして機能させています。次に、サーバーはそのデータ プロバイダー (データベースを使用する) を注入し、クライアントはサーバーを使用するデータ プロバイダーを注入します。
これが合理的なアプローチのように思えるかどうか疑問に思っていますか?DAL オブジェクトをクライアントに直接公開するのではなく、別のレイヤーが必要かどうか疑問に思っています。おそらく、データ転送オブジェクト層で、データ アクセス オブジェクト、ビジネス ロジック オブジェクト、およびデータ転送オブジェクトの 3 つの層が得られます。
ありがとう。
architecture - RIAサービスとBLL
現在、Silverlightエンタープライズアプリケーションの開発をスピードアップするために、RIAサービスを検討しています。それは賢くて強力ですが、あなたは常にビジネスロジックをプレゼンテーション層に崩壊させようとしているように私には思えます。RIAを使用する場合、従来のBLL(ビジネスロジック層)を配置する場所はありますか?
更新:さらに調査を行いました。現在受け入れられているベストプラクティスは、MVVMを使用してRIAを実装し、VMをクライアント側クラスとして動作させ、ビジネスロジックを含めることです。
nhibernate - NHibernateとコンテキスト変更データベースを使用したレイヤードアプリの設計
私はC#アプリケーションを設計しています
- プレゼンテーション(Webサイト+フレックスアプリ)
- ビジネス論理レイヤー(マルチクライアントプラットフォームを有効にするためのWCFの場合があります)
- データアクセス層(NHibernateを使用)
ソリューションを多くの既存のクライアントのデータベース環境に統合し、DALでNHibernateを使用したいと思います。私の同僚は、NHibernateを使用してクライアントのDB(ユーザーやイメージなど)からクラスを生成するとBLLが爆発することを指摘しましたDBが変更されるたびに私たちの顔に現れます!それで問題は、それが起こらないようにするにはどうすればよいのかということです。AutoMapperを使用してビジネスオブジェクトを作成し、NHibernateオブジェクトをこれらのBOにマッピングして(ハム、それはDTOになりますか?)、dalの変更がBLLに影響を与えないようにすることを検討しています。
ありがとう !
編集 :
私たちが達成しようとしていることをよりよく理解するには、コンテキストが必要になる場合があります。フロントエンド用にFlexで、バックエンド用にC#で写真の保存/共有アプリを構築しているため、主に当社向けです。コードとDBのあらゆる側面を処理します。
ただし、その製品は層によって購入することもできます。層は、最終的にはユーザーテーブルまたはイメージテーブルを含むデータベースをすでに持っています。ここでは、数億行のImageテーブルがあり、テーブルのALTERが長すぎるために、ビジネスロジックに列を追加することはないという新しい見込み客について考えています。
可能であっても(たとえば、行が少ないためにユーザーテーブルを変更できる)、BLLから層データベースに統合する必要があるたびに、すべてのソリューションに影響を与えることなく、テーブル構造の変更を処理する方法を自問しています。 Flexのクライアントアプリに!
c# - BLL と DAL 間の通信
ソリューションのセットアップ:
- DAL (クラス ライブラリ)
- BLL (クラス ライブラリ)
- 共通 (クラス ライブラリ (いくつかの共通機能 - 列挙型、ロギング、例外など))
- アプリケーション 1 (Windows アプリケーション)
- アプリケーション 2 (Windows アプリケーション)
- WebApp (Web アプリケーション)
- ...
次のCustomerエンティティがあるとします。
- SQL サーバーのテーブル
- DAL の CustomerDataTable
- BLL の Customer クラス
- すべてのアプリケーションの BLL.Customer クラス
BLL と DAL はどのような種類のオブジェクトを通信に使用する必要がありますDataTable
かList<Customer>
? (たとえば)? 最初のケースでは、BLL ロジックは Customer オブジェクトを DataTable に変換し、それを DAL に送信する必要があります。2 番目のケースでは、DAL レイヤーは、BLL レイヤーにある Customer クラスを認識する必要があります。しかし、もともとDLLはDALを参照しており、反対ではありません...
すべてのクラスを、他のすべて (Common、BusinessObjects など) から参照される個別のアセンブリに配置する必要がありますか? この場合、すべてのプロジェクトで Customer クラスを使用できます。
1 つの BLL だけが DAL を使用することがわかっている場合でも、わざわざ DAL と BLL を分離する必要があります。この場合、それらを 1 つのプロジェクトにマージできます。
PS - 私は DataTables について読んでいますが、多くの人が DataTables をまったく使用すべきではないと言っています。より良いオプションは何ですか? たぶん、ORMマッピングツールを学ぶ時が来ました:)
silverlight - 中間層-C#クラスライブラリまたはWCF?
私は、ビジネス層とデータアクセス層を必要とする新しいビジネスアプリケーションを開発しています。
現在、Silverlight RIAアプリとWCFアプリ(SOAP Webサービスとして公開される)によって使用される単純なC#クラスライブラリとして両方を持っています。
WCFライブラリを使用するのではなく、C#クラスライブラリとしてこれらの層を開発することに何か問題はありますか?
したがって、Silverlight-> RIA(ASP.Net)-> BLL C#クラスライブラリ-> DAL C#クラスライブラリ-> EF->SQLServerの代わりに
Silverlight-> RIA(ASP.Net)-> | (ウェブ)| ->BLLWFCライブラリ->DALC#クラスライブラリ-> EF-> SQL Server?
business-objects - BLL はステートレスにする必要がありますか?
アプリケーション用の BLL を構築しようとしています。私が見たり読んだりしたことから、BLL はステートレスであるべきだと思われます。これは、すべての BLL メソッドが静的である可能性があるということではありませんか? または、少なくとも各 BLL クラスのインスタンスが 1 つだけ必要ですか? なんらかの理由でこれは私には奇妙に思えるので、実験を深く掘り下げる前に、棒の端が間違っていないかどうかを確認したほうがよいと思いました.
また、データは状態を表すため、BLL オブジェクトにデータが含まれてはならないことも意味すると考えています。そのため、呼び出された BLL 操作ごとに、必要なデータを再クエリ (またはキャッシュからフェッチ) してから破棄する必要があります。それは正しいと思いますか?
ありがとう。
c# - aspコントロールイベントをBLLに入れようとすべきですか?
最近、データアクセス層、ビジネスロジック層、プレゼンテーション層について学びましたが、まだはっきりしていないことがいくつかあります。
プレゼンテーション層でDALとBLLを使用して、データベース内の情報を取得または設定できます。
しかし、aspコントロールイベントと、それらをどのように実装するかについても考えました。
たとえば、ボタンクリックイベントをBLLに入れようとする必要がありますか、それともaspxコードビハインドファイルに残す必要がありますか?
そして、それらをBLLに入れる必要がある場合、これをどのように実行しますか?
BLLにあるメソッドをイベント呼び出しする方法がわからないので、アドバイスをいただければ幸いです。
c# - デザイン パターン: この概念と、それが私のプロジェクトにどのように適用されるかを理解するのに助けが必要です
ここ数日、私は DAL/BLL/UI アプローチを使用して多くの調査を行ってきましたが、それが私のプロジェクトにどのように適用されるかについて明確に理解していませんでした。以前は、UI をデータ アクセス層 (LINQtoSQL dbml) に直接接続する BLL を省略していました。しかし、これは私が現在 (または過去に) 働いている場所では良い考えではないと思います。なぜなら、私たちは多くの異なるアプリケーションを持っており、それらが構築されているのと同じ DAL/BLL を使用したいからです。
私の質問は、ほとんどのアプリケーションで、LinqtoSqlDataSource/GridView を使用してデータコンテキストに接続し、すべての更新/編集などを処理するだけである場合、BLL がどのように役立つかということです。また、新しい Web ごとに、アプリケーションは、あるレベルで、必要なデータを取得するために DAL/BLL に独自の変更を加える必要があり、同じ DAL/BLL を使用する他のアプリに影響を与える可能性があります。この DAL/BLL の再利用はこれを行う正しい方法ですか、それとも何か不足していますか?
ビルドするさまざまな Web アプリケーションのセキュリティ クラスなどをビルドする必要がある場合に、BLL が役立つと思います。しかし、Linqtosqldatasource を使用する場合、わざわざ BLL に接続する必要があるのでしょうか。
ダル
- LinqToSQL dbml データ コンテキスト。
- LinqToSQL を使用すると、この設計の使用方法が変わりますか?
BLL
- 企業が利用する各種Webサイトのセキュリティ。
- Query DAL return what(?) when using LinqToSQLDatSource., さまざまな結果セットを処理する関数 (これが BLL でどのように機能するかは本当にわかりません。質問が不明な場合は申し訳ありません)
UI
- BLL のみを参照しますか?
asp.net - BLL を使用したリピーターの作成
データベースのデータにバインドされたリピーター コントロールを作成しようとしています。これは、BLL で使用する必要があります。しかし、私は何をしなければならないのかわかりません。
誰かがこれで私を助けてくれることを願っています..
page.aspx.vb で使用したコードは次のとおりです。
page.aspx で使用したコードは次のとおりです。
asp.net - Webアプリケーションのグローバル変数の作成-ASP.NET
dbに接続するためのWebアプリケーションを構築しています。これまでのところ、私はそれに対処することができました(ただし、BLLとDALは作成していません)。
列「id」を持つテーブルがあります。SQLServerで自動的にインクリメントされるように宣言する方法があることを私は知っています。(しかし、私はそれを望んでいません)。
値を保持するグローバルアプリケーション変数を宣言したい。
私は2つの質問があります:
どのように私はそれを宣言しますか?
どこで作成して初期化しますか?(私はいくつかのログインページを持っています)。
ありがとう!
ps
誰かがストアドプロシージャを使用してDALを構築する方法を教えてくれると助かりますか?そして、私が必要とするもののために、私はDALではできないBLLを使用しますか?