業務アプリケーションの実践的なアーキテクチャを公開 ー CodeZine記事 | MESCIUS.devlog - メシウス株式会社
これを「グレープシティ製品の記事」と紹介して良いのだろうか？ その濃密な内容に驚き、通常の製品紹介記事と同列にするのはもったいない！ そう思わせる文書が公開されましたので共有します。 その記事は、東京のSI企業に勤務する現役エンジニア、アーキテクトである中村充志さんが執筆し、 デベロッパーの成長と課題解決に貢献するメディア「CodeZine」で公開されました。 中村さんは、主にWPFやASP.NETをプラットフォームとする業務システム開発が本業ですが、活動範囲は幅広くXamarinに関する技術書籍の執筆や、今回の記事でも採用しているMVVMフレームワーク「Prism」のコントリビューターです。 また、XamarinやPrismをテーマにした講演でもご活躍されています。 今回公開された記事は、概要編、実践編の二部構成です。 MicrosoftのサンプルデータベースであるAdventureWo
O/Rマッピングツールに対する誤解をときたい -実装編 Part9- - give IT a try
Part8を読む これまでのまとめ 当初考えていた以上に長いシリーズとなってしまったので、一度全体を振り返ってみます。 また、その後でO/Rマッピングツールを採用するかどうかの判断基準や考慮点、アンチパターンなんかも書いてみたいと思います。 これまでに書いてきたエントリの概要 O/Rマッピングツールに対する誤解をときたい このシリーズの出発点となった「元ネタ」です。 とあるコラムの議論を読んでいて、「なんか論点がおかしいな〜」と感じたのでこのエントリを書きました。 O/RマッピングツールはSQLを書きたくない人のためのツールではなく、インピーダンスミスマッチ問題を解決するためのツールであるということを文章で説明しています。 実装編 Part1 Part1ではサンプルプログラムの仕様について説明しました。 またインピーダンスミスマッチ問題を解決する過程よりもむしろ、O/Rマッピングツールが実
モデルを中心としたソフトウェアアーキテクチャを採用する意義 - give IT a try
今とある新規社内システムの設計と開発を担当しています。 ソフトウェアアーキテクチャはおいらが考えました。 簡単に言うとこんな感じです。 UI層/サービス層/データアクセス層の3レイヤーに分ける 開発言語はC#、UIはASP.NET、データアクセスはADO.NETを採用 (バージョンはいずれも2.0) データのやり取りはデータベーススキーマから自動生成した型付けデータセットを使う MVCで言うところのModelが型付けデータセットで、ViewとControllerがASP.NETです。 サービス層は基本的にこの型付けデータセットを出し入れします。 つまりテーブルの行単位でデータをやりとりします。 で、こういうスタイルのアーキテクチャに慣れていない開発者には、どうもこれが非効率で面倒なアーキテクチャに見えるようです。 まあ確かに言わんとすることは分からんでもありません。 例えば本のISBN、タ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoftによる.NETアーキテクチャの手引きに関する発表
A generic repository
Application Architecture for Enterprise Win Store Apps with DDD Pattern
