実践! ソフトウェア アーキテクチャ
Visual StudioASP.NETによる業務システム開発方法〜

[表紙]実践! ソフトウェア アーキテクチャ〜Visual StudioとASP.NETによる業務システム開発方法〜

A5判/288ページ

定価(本体2,380円+税)

ISBN 978-4-7741-3178-8

ただいま弊社在庫はございません。

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

「.NET TECHNOLOGY」シリーズ第2弾となる本書は,Visual Studio 2005と.NET Frameworkを用いた業務アプリケーションの具体的なソフトウェア アーキテクチャについて書かれた本である。

本書では「プログラミングを極めた人間」を“ソフトウェア アーキテクト”と定義し,ソフトウェア アーキテクトが作ったソースコード(ソフトウェア アーキテクチャ)をテンプレートとして活用して,業務アプリケーションを開発していく方法を解説している。まず1章でソフトウェア アーキテクチャを定義し,2章で示すサンプルアプリケーションを題材として,3章〜10章で具体的に作成していく。非常に現場寄り,実践的な内容の書籍となっており,.NET開発者必読である。

こんな方におすすめ

  • .NET開発を行っているプログラマ,さらに知識を深めたい開発者

この書籍に関連する記事があります!

実践!ソフトウェア アーキテクチャ~Visual StudioとASP.NETによる業務システム開発方法~
IT業界とは,この3Kで表現できる職業なのだそうです。あとは,きつすぎて心を病んじゃったり,帰れない(定時にじゃなくて家に)ので臭かったり,たとえ給料が高くても資質がなくて彼女できなかったり結婚できなかったり…。

目次

第1章 ソフトウェアアーキテクチャとは?

  • 1-1 ソフトウェアアーキテクトとは?
    • 1-1-1 ウォーター フォールの "キャリア パス" には問題がある
    • 1-1-2 プログラマの生産性には,大きな差がある
    • 1-1-3 プログラマからソフトウェアアーキテクトというキャリア パス
  • 1-2 ソフトウェアアーキテクチャとは?
    • 1-2-1 ビジネス アプリケーションでは,標準化が有効である
    • 1-2-2 まずは,クラス ライブラリを作る
    • 1-2-3 そして,クラス ライブラリを呼び出す部分も作る
    • ●コラム アスペクト指向プログラミングは使わないの?
  • 1-3 補講:プログラミングを知らない設計者による設計のやり方
    • 1-3-1 RDBMS以前。COBOLな人が処理に注目しがちな理由
    • 1-3-2 ER図。各論に入らずに全体像を作成する
    • 1-3-3 Table Moduleパターン。重複のない形に機能を構造化する

第2章 サンプルアプリケーションの仕様

  • 2-1 ER図
  • 2-2 スマート クライアント
  • 2-3 Webアプリケーション
  • 2-4 セットアップの方法

第3章 アプリケーションの全体構造

  • 3-1 Layersアーキテクチャ パターン
    • 3-1-1 アセンブリのレベルでカプセル化
    • 3-1-2 重ねて積んで,下のレイヤをカプセル化
    • 3-1-3 レイヤに意味を持たせて標準化しましょう
  • 3-2 Patterns&Practicesでの全体構造
  • 3-3 本書におけるビジネス・アプリケーションの全体構造
    • 3-3-1 不満点1:エンタープライズの視点が足りない
    • 3-3-2 不満点2:サービス エージェントは処理にも使える
    • 3-3-3 不満点3:ビジネス エンティティはデータ レイヤ
    • 3-3-4 不満点4:ユーザ インターフェイス プロセスはなんだか胡散臭い
    • 3-3-5 本書におけるビジネス アプリケーションの全体構造

第4章 ビジネス エンティティ

  • 4-1 型付DateSetって便利
    • 4-1-1 思考実験:SQLを発行する "だけの" アプリケーション
    • 4-1-2 ビジネス エンティティが必要な理由
    • 4-1-3 プレゼンテーションまでと考えると,型付DateSetが便利
  • 4-2 オブジェクト指向しゃなくていいの?
  • 4-3 型付DateSetを用いたビジネス エンティティ
    • 4-3-1 ソリューションとプロジェクトの作成
    • 4-3-2 RDBMSのスキーマを作成
    • 4-3-3 型付DateSetの作成
    • 4-3-4 プロパティとメソッドの追加

第5章 データ アクセス ロジック コンポーネント

  • 5-1 JOINする?しない?
    • 5-1-1 表を編集するとなると…
    • 5-1-2 テーブル単位で取得する
    • 5-1-3 JOIN演算の説明
  • 5-2 関係するテーブルを正しく巡り,サイクルデッドロックが発生しないように更新する
    • 5-2-1 クラス ライブラリを作成してみる
    • ●コラム CallFillTableAdapters()メソッドを実装できた理由
    • ●コラム イテレータは非常に便利
    • 5-2-2 更新する場合を考える
    • 5-2-3 追加/削除の場合を考える
    • 5-2-4 サイクル デッド ロックを防ぐ
    • ●コラム サイクル デッド ロックとは?
    • ●コラム Table Moduleパターンはどうなった?
    • 5-2-5 ロスト アップデートを防ぐ
  • 5-3 TableAdapterを用いたデータアクセス ロジック コンポーネント
    • 5-3-1 TableAdapterの作成
    • 5-3-2 Taillsland.RX的なTableAdapterの呼び出し
    • 5-3-3 特殊ケースへの対応

第6章 ビジネスコンポーネント

  • 6-1 Table Moduleで設計者と良い関係を築きましょう
    • 6-1-1 設計者とは,ビジネスの専門家である
    • 6-1-2 ransaction ScriptとDomain ModelとTable Module
    • 6-1-3 Table Moduleなら,設計者にプログラミングの知識は不要となる
  • 6-2 トランザクション管理を考える前に…
    • 6-2-1 アシッドトランザクション
    • 6-2-2 ショートトランザクションとロング トランザクション
  • 6-3 TransactionScopeでReadCommittedなショート トランザクション
    • 6-3-1 トランザクション管理方式はTransactionScope
    • 6-3-2 IsolationレベルはReadCommitted
  • 6-4 作りこみによるロングトランザクション
    • 6-4-1 競合が発生する場合は,排他ロジックを作りこむ
    • 6-4-2 補償トランザクションを作成する
  • 6-5 ステート管理とロギングとエラーと主キー設定
    • 6-5-1 ステート管理
    • 6-5-2 ロギング
    • 6-5-3 エラー
    • 6-5-4 主キーの設定
  • 6-6 ビジネスコンポーネントの作り方
    • 6-6-1 ソリューションにTaillsland.RXを追加
    • 6-6-2 共通メソッドの作り方
    • 6-6-3 独自メソッドの作り方
    • 6-6-4 Validatorの作り方

第7章 ユニットテスト

  • 7-1 テスト駆動開発
    • 7-1-1 テストの自動化
    • 7-1-2 リファクタリング
  • 7-2 自動テストの対象
    • 7-2-1 プレゼンテーション レイヤは自動テストしない
    • ●コラム テスト騒動開発の落とし穴
    • 7-2-2 プレゼンテーション レイヤは自動テストしない
    • 7-2-3 RDBMSを使ってテストしちゃえ
  • 7-3 ユニット テストの作り方
    • 7-3-1 テスト プロジェクトを追加
    • 7-3-2 データベース プロジェクトを追加し,初期化スクリプトを登録
    • 7-3-3 ユニット テストの一般論
    • 7-3-4 ユニット テストを作成
    • ●コラム privateメソッドに対するユニット テスト

第8章 サービス インターフェイスとサービス エージェント

  • 8-1 XML Webサービス
    • 8-1-1 XMLを使用したメッセージ交換
    • 8-1-2 XML Webサービスを採用する理由
    • 8-1-3 通信の粒度に関する推奨事項
  • 8-2 サービス インターフェイスの作り方
    • 8-2-1 XML Webサービスの作り方の一般論
    • 8-2-2 エラー処理
    • 8-2-3 性能を劣化させないための安全弁の取り組み
  • 8-3 サービス エージェントの作り方
    • 8-3-1 wsdl.exeを実行してスタブを作成
    • 8-3-2 データベース プロジェクトを追加し,初期化スクリプトを登録
    • 8-3-3 クライアントのValidatorを作成,サーバのValidatorを修正

第9章 プレゼンテーション レイヤ(スマート クライアント)

  • 9-1 画面はテーブルを元に設計しましょう
    • 9-1-1 ER図から画面設計への変換指数
    • 9-1-2 正規化って素晴らしい
    • 9-1-3 ルールは破るためにあるけれど,高くつくことが多いので注意
  • 9-2 データ バインディングでソース コードを激減させましょう
    • 9-2-1 表のデータ バインディング
    • 9-2-2 表のデータ バインディング
    • 9-2-3 子テーブルのデータ バインディング
  • 9-3 Taillsland.RXでのデータ バインディング
    • 9-3-1 データ ソースにサービス エージェントの型付DataSetを追加する方法
    • 9-3-2 XML Webサービスの呼び出しには注意が必要
    • 9-3-3 カラムのエラーはErrorProvider,レコードのエラーはダイアログ
    • 9-3-4 画面遷移にまつわるエトセトラ
    • 9-3-5 行の削除では,子テーブルの行も削除する
    • 9-3-6 コントロールに入力可能な長さを設定
    • 9-3-7 イベント ハンドラでは,例外をハンドリンクする
  • 9-4 スマート クライアントの作り方
    • 9-4-1 プロジェクトの追加
    • 9-4-2 表形式のフォームの作り方
    • ●コラム リレーショナル データベースを更新する単位

第10章 プレゼンテーション レイヤ(Webアプリケーション編)

  • 10-1 Webアプリケーションよりスマートクライアントの方が好き
    • 10-1-1 イントラネットなら,漸近的なユーザビリティ向上で楽ちん
    • 10-1-2 イントラネットのアプリケーションはどっちが良い?
  • 10-2 データ バインディングは,ASP.NETでもそれなりに便利
    • 10-2-1 単一値のデータ バインディング
    • 10-2-2 集合のデータ バインディング
  • 10-3 ASP.NET検証コントロールは非常に便利
  • 10-4 画面遷移はResponse.Redirect()で
    • 10-4-1 ポスト バックという方式
  • 10-5 ASP.NETメンバシップはかなり便利
  • 10-6 Global.asaxはサービスインターフェースのときと同様に