.Net Core / Net ASP Core [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
おらの群馬さにはIISなんてねえもんでりなっくすさ使ってしぃしゃーぷさ動かすべえな こんなの動くなんておったまげえな時代だわな んだいくべえ >>323 asp.net core のスキャッフォルド機能だよ entity入れたらコントローラとビューを作るやつ 一緒にviewModelとかも作りたいし、efのマイグレーションも一緒にやりたいんだが そういうニーズは無いのかねえ? >>327 んー、今んとこ考えてたのは、 1)既存テンプレのカスタマイズだけじゃなくて、ControllerやView以外のファイルを吐き出す。今のところ、Entityに対応するViewModelと、モデルファット実装したいからソレ用のモデルクラス。 2)efのadd-migration, update-database を実行するオプションの追加。 3)DIコンテナへの登録、dbContextへのDbSet追加やらの、既存ファイルへの追記。 の3つ。 dotnet aspnet-codegeneratorで自作パッケージ上の実装を読ませるサンプルが見つかったんだが、サンプルは引数をトリガにして自分の実装へ誘導するまでで終わってて、ファイルの生成までは書いてない。 で、御本家githubのaspnet/Scaffoldingを読んでて面倒くせえわ誰かもうやってんだろ、となった。 >>328 Entityに対応するViewModelとモデルファットってのがよくわからんが MVCモデルで書いててモデルファットが通じないってマジかよ コンローラにロジック盛り盛りなの? システム運用開始後に運用者側でモデルを変更したいって話? それは俺も今考えててデータはJSONで保存してビュー側でJSONのないようにて 動的にテンプレート変更するしかないのかな状態。 fat modelを実装したい←意味わからん 設計ミスってfat modelになってしまった←意味わかる 失敗した結果をfat modelという それをなんで実装したいの? ああ、なんかスマン、煽り気味に書いたのに割とマジな回答も貰っちまって微妙な気分。 LL言語系FWのMVCモデルでユニットテストを書きやすくするため、単純なInputに対して単純なOutputを返す"モデル"に実装を寄せる考え方をモデルファットって言うのね。 Rails系が流行ったあたりから今も変わらない、所謂Web系の皆さんの基本アプローチになってて。 ASP.Net MVCを触ってて、MS世界というかASPの思想上には無い概念だ、というのは分かった。 ただ俺の都合として、社内でRails系FWに慣れ親しんだ連中をこっちに誘導したいわけですわ。 よって昔ながらのFWにある機能は一通り用意した、ASP版FWを当てがってやるつもりでいる。 その一環でスキャッフォルド機能も実装中だった、というわけです。 モデルファットじゃなくファットモデルな ファットコントローラーを嫌ってモデルに処理を移動したのはいいが 単にモデルを巨大化させただけでファットコントローラーとやってること同じじゃんっていうやつね ファットモデルになってしまったという事はあるけど狙ってファットモデルにするって事はありえないよ なのでそれをサポートするフレームワークも当然ありえない スキャフォールドはリバースエンジニアリングでもリファクタリングでもないだろう スキャをどうこうじゃなくて、リファクタリング系の充実を望むって話じゃないか なんでそういう無意味なことをするのかが理解できん 頭悪そう なんのかの言うだけでネタはねーのかよショボチンやなー 結局ご本家ソース読んでたら出来ちまったわ しっかし、モデルを太らず実装を拒絶するMVCerってのは正直生まれて初めて見たな...ちゃんとテスト書いてのかよw 太り過ぎたら分割すりゃいいし、分割するにもController分割よかずっと楽だろうに Identityのソースでもやってる実装やし、別にフツーのことやぞ? >>340 君のなにが悪かったかっていうとモデルファットと言ってしまったことだよ そもそもモデルファットじゃなくファットモデルというのは見逃すとしても ファットモデルってのはファットコントローラーと同じアンチパターンのこと それを当たり前の王道みたいな風に言ったからおかしなことになった コントローラーから処理を抽出してモデル(サービス)に移動するのは当たり前の王道 ファットモデルはその王道をよく理解せずにコントローラーに無ければいいんだろ?と考えなしにモデルを拡張して破滅するアンチパターンのことを言う .net core 2 でSQLサーバとを連携させて、 スキャフォールディングなどを使ってみたいんですが、 対応しているSQLサーバのバージョンの制限などあるでしょうか。 今、たしかexpressの2010版が動いていると思います。 >>342 たぶんEntityFramework Coreのことだよね?SQL Serverなら2008以降が対応してる >>343 レスいただきありがとうございます! そうです。EFのことです。 ところで、EFはストアドプロシジャのモデルバインドに対応していないのは残念。 >>345 そういうのもあるんですね。 自分は次の方法です。 DBContextの、FromSqlというメソッドで、 パラメーター付のストアドプロシジャ(SELECT文)も呼び出せるようです。 INSERT UPDATE DELETEは、 EXecuteSqlCommandAsync というメソッドを代わりに使えるようです。 Microsoft.EntityFrameworkCore.Relational パッケージを、導入している必要があるそうです。 どっちのパッケージがいいんでしょうか。 >>346 それめっちゃ遅いから、ストアドプロシージャならDapperの方がいい >>347 アドバイスありがとうございます。 先輩に従わせていただきます!! Apologies for lack of ODP .NET Core status updates. Beta coming very soon. https://twitter.com/OracleDOTNET/status/955487498922164224 odp.netね もうポスグレに移行しちゃったよ 脱ORACLEかなり捗った Javaのretrofitみたいな感じでタイプセーフなrest api clientをビルドするためのdot net coreライブラリって無いの? モデルオブジェクトの定義で、 [Table("任意の日本語テーブル名")]属性 [Column("日本語の列名")]属性 は使えるでしょうか。 asp.netでは、説明がありますが、 core2ではどうなのかなと思って。 >>357 EntityFramework Core2.0のことを言ってるんなら使えるよ >>358 わー、さっそくレス頂きありがとうございます そうです。 EntityFramework Core2.0 のことです。 パッケージ導入して、環境を準備して、 やってみたいと思います。 EntityFramework Core2.0では、規約がものをいうので、日本語のテーブル名、列名を使っているデータベースでも大丈夫なのか不安なのでした。 ハローワールドは成功したので、dbcontext、エンティティ、そしてテストコードを書くところです。 EntityFramework Core2.0って、コードファーストや、データベースファーストを推してくるんですが、そういう自動生成機能って、使わないで、自分で両方の定義をしてもいいのですよね。 皆さんはどういう風にしているのだろうか。 >>360 日本語のテーブル名とか、列名つかってなかったの? 英語の複数形をテーブル名にしてたとか、ルールを意識して構築してたのかな。 >>362 日本語なんて使うわけないけど、何をそんなに心配してんの? >>362 まさか複数形じゃないとテーブル名として使えないとでも思ってる? >>363 sql server 7.0の頃から構築したテーブルで、 日本語のテーブル名と列名が使われているんだよ。 そのままスキャフォールディングするのも心配。 日本語のクラス名とかプロパティーなんて見たくないし。 >>364 いや、規約から外れていると何か不具合が発生しそうで。 >>368 水色の.net coreの参考書しか読んだことない。 あと、薄紫色のASP.NET MVCの書籍とか。 ドキュメントなんかあるんか? >>367 View? htmlを描画するやつのことではないと思うけど。 sqlのviewだと思うが、書き込みは普通にテーブル使うしか無い どうしても避けたいのならWebAPIでも使うのが最善かも DBがインストールされたサーバー内だけなら日本語テーブル名問題は起こらないだろうから その後を全部英文字にすればトラブルフリーに出来るかもしれん >>375 うん、でも嫌いではないんだけどね、多分、カバーで隠して読むだろうね >>376 電子書籍だからカバーもクソもないと思うが ASP.NET MVC の 知識ってほとんどそのまま、.net core MVC で通用すると考えていいのかな? スキャホールディングしなくても、それが出力するようなコードを、 モデルと、DbContextに自分で全部書き起こせば、 データベーステーブルでテーブルの結合したやつでも得られるんだろうか。 データベースでリレーションの設定をしていないので、スキャホールディングでテーブル結合反映されないため、 自分でコードを記述しようと思っているんです。 データベース側は既存のプログラムとの連携が壊れたら困るのでいじりたくありません。。 業務系は複雑怪奇なレガシーDBの呪縛があるからEFとの相性が最悪 SQLを手で書いてDapperでマップするのが正解だよ >>385 壊してもいいデータベースで開発してから、 それを本番のデータベースで運用する予定 >>384 Dapperについて調べてみます。 ストアドプロシジャとパラメーターがつかえたらいいんだけどなあ >>386 ストアドプロシージャとパラメーター使えるよ Dapperでは、SQLやストアドプロシジャの結果行に対応したモデルクラスに、 マッピングできるのだとわかってきました。 自分のところのストアドプロシジャでは、テーブルにはない新しい列が登場したり、列の名称が付替られたりするので、 ストアドプロシジャの結果行に対応した専用のクラスをいちいち作成しようと思いました。 ストアドプロシジャでは最終的に、SELECT文で出力したい列が列挙されています。 対応するクラスのプロパティー名(日本語)と列名(日本語)を一致させておけば、 列挙の順番は関係ないでしょうか。 >>389 そうだよ 基本的に名前を見比べて1行と1オブジェクトに変換してくれるだけ 変換ルールのカスタマイズも出来るけど保守性がよくないから避けたほうがいい >>391 レスありがとうございます! 既存のストアドプロシージャーを使って、 テストコードを試してみたいと思います。 結果をマッピングできるのはとても便利ですね。 ありがとうございます! >>390 列名が日本語で書かれているんですよ。 select ID,名称 from ほにゃらら みたいな感じでデータを引っ張って来る必要があるので、 マッピングするC#クラスのプロパティーも、こういうのに合わせる必要があるわけなんです。 日本人なら分かり易いというメリットはあるんですが、 システム上の互換性でいつか面倒なことにならないかと心配しますね。 >>394 ありがとうございます。 なるほど、そうすれば英語表記のモデルクラスが使えるということですね。 日本語クラス名、プロパティー名で結構だというのなら、使う必要はないという理解でいいのかな? ところでこれは、DBContextの、関連付けとちょっと似ていますね。 メソッドチェーンしながら、ラムダ式を与えて、エンティティーの定義を行っていました。 >>391 さんのおっしゃる、 ”変換ルールのカスタマイズも出来るけど保守性がよくないから避けたほうがいい” というのは、この>>394 さんのおっしゃっているカスタマイズのことなんだろうね。 sqlのasを使うと簡単だね ただoracleだとasしても英訳した列名が30文字に収まらない場合がある DBの物理的な制約を気にしたくないなら DTOからドメインオブジェクトにマップする時に物理名を論理名に変換すればいいよ DTOは日本語を含んでよい ドメインオブジェクトは日本語を含まない 変換処理はC#で手作業で書く DapperでDTOを取得して変換処理に流し込む >>397 >変換処理はC#で手作業で書く >DapperでDTOを取得して変換処理に流し込む これは、どういうことですか? Dapperはドメインオブジェクト(モデルクラス)に行データを自動的に変換してくれるものだと理解してます。 そして、必要なら、日本語の列名を、クラスの英語名のプロパティ名に変換するために、>>394 さんの方法を使うのですね。 Dapper自体と、DTOとの区別がわかりません。 いったん取得した行データの日本語名プロパティを含むクラス型を、完全英語名のクラス型に値をプロパティごとにC#でコピーするということでしょうか? DapperはSQLの結果セットをDTOにマッピングしてくれるだけ DTOからドメインオブジェクトへのマッピングは別途用意しなければならない DTOとドメインオブジェクトを同一視してマッピングを省くことは可能だけど それをやるとドメインオブジェクトが歪な構造になるのでオススメしない >>399 >DTOとドメインオブジェクトを同一視 >DTOとドメインオブジェクトを同一視 自分はその同一視をしていたのかもしれない。これは、アプリの設計に深く関わる問題ですね。 ドメイン駆動アプリ?だかの参考書を読んでいたときのことを思い出しました。 でも知識を使う前に、すっかり忘れていました。 最初、こんなつもりでした。 例えばこんな感じで、モデルクラスを定義して、 自分の場合、データベースの日本語列名に合わせて、日本語のプロパティー名で定義して、 public class 人間 { public int Id { get; set; } public string 名前 { get; set; } } そして、 SQL Server → Dapper →「人間クラス」 (こうして、人間クラスに行データがマッピングされる。だから、「人間クラス」がDTOでいいのかな。) で、 ControllerのActionメソッドとかから、この「人間クラス」のオブジェクトにアクセスして、 Viewなりに渡そうとしていました。 ああ、これでは同一視になりますよね。 つづく↓ >DTOからドメインオブジェクトへのマッピングは別途用意しなければならない SQL Server→Dapper→「人間クラス(DTO)」→→(変換)→→「ドメインオブジェクト」 なるほど。>>397 でおしゃっていたことが理解できたかも。 DTOまでは、日本語名のクラス名やプロパティーでもOkなわけですね。 しかし、ドメインオブジェクトという形に、変形してアプリに統一性を持たせるべきで、 そのときに(ついでに)、英語に統一すればいいというわけなのか。 もし、私の理解が間違っていなければ、目から鱗でした! ありがとうございます。もう一度、設計のための参考書を開いてみたいと思います。 勉強したことを使わないうちに、どんどん忘れてしまう。。。。 しかし、こうして、 日本語名から英語名への統一でも、ドメインオブジェクトという考え方が役に立つんですねえ。 ありがとうございます。 >>402 DTOからドメインオブジェクトへの変換は一パターンとは限らない だからDapperからDTOにマッピングする時点で、c#の規約に沿った形のクラス/プロパティ名にしておくと便利 じゃなきゃAutoMapperすら使えないし >>403 どこで、日本語名の列を、英語名のプロパティーに変換するかという問題なんですよね。 SQL Server→Dapper→「人間クラス(DTO)」→→(変換)→→「ドメインオブジェクト」 SQL Server→Dapper→→(変換)→→「人間クラス(DTO)」→ ※ →「ドメインオブジェクト」 ところで、AutoMapperは、上記の※の位置に来るという理解で正しいでしょうか。 DBには日本語つかうのに、プログラムに日本語使うのを嫌がるのが理解できん >>405 var p = new 人間(); var n = p.名前; こんな感じなのは、普通ってことでしょうか? カスタムルールはメンテナーがカスタム手順わからなくて困るパターン 手動マッピングなら5分で書けるのにルール設定がわからず1時間ハマりっぱなしとかよくある >>409 >>404 のように、 DTOとドメインオブジェクトとのあいだで、 手動変換するということですね ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ EF Coreはまだまだみたいだから、とりあえずDapperで使えればいいや Kestrelのhttp2対応ってどの辺までできたのかしら? kestrel(というかasp.net core)がまだPush対応されてなくて無事死亡 goを触ってからだとビルドとかパッケージ管理とかの遅さが気になって使えない warn: Microsoft.AspNetCore.Server.Kestrel[22] Heartbeat too longer than "00:00:01" at "03/07/2018 10:00:00 +00:00" こんな警告が出るんだけどどういう意味? 解決方法教えて >>421-422 色々と洗ってみたけどダメでした 再現性もなくログには不定期に出力されてるからKestrel側の問題なのかな でもありがとう ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる