.Net Core / Net ASP Core [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
おらの群馬さにはIISなんてねえもんでりなっくすさ使ってしぃしゃーぷさ動かすべえな
こんなの動くなんておったまげえな時代だわな
んだいくべえ >>99
>>86
まあ撤回したけどね
当該issueには何の説明もなかったけど >>101
xmlは面倒です
スクリプトはないんですか? >>103
最近の流行りはCake
昔からあるのはFAKE .NetCoreって、iOSやAndroid用のランライムを作る計画は無いの?
monoは遅くてつらい modelのvalidation rulesを流用というか複数に適用するやり方ってある?
元のテーブルと外部テーブルをjoinして作られたviewとで同じものを二度記述するのが気になってる
例えばこんなの
public class Movie
{
[StringLength(60, MinimumLength = 3)]
[Required]
public string Title { get; set; }
}
public class User
{
[StringLength(100, MinimumLength = 2)]
[Required]
public string Name { get; set; }
}
TitleとNameは同じなので二回宣言するのが腑に落ちない
↓
public class UserMovie
{
[StringLength(60, MinimumLength = 3)]
[Required]
public string Title { get; set; }
[StringLength(100, MinimumLength = 2)]
[Required]
public string Name { get; set; }
} struct MovieTitle {
public string Value { get; set; }
public bool Validate() { return ...; }
}
struct UserName { ... }
class Movie {
public MovieTitle Title { get; set; }
public bool Validate() {
return Title.Validate(); }
}
class MovieUser {
public MovieTitle Title { get;set;}
public UserName Name{get;set;}
public bool Validate() {
return Title.Validate() && Name.Validate(); }
}
これじゃいかんのか?
属性って不便だし邪道だし
なんでこんなものをありがたがるのかわからん 属性使った方が Readability は高いけどな。
おまえのコードだと検証部分のコードまで読まないと要件がわからんわ >>109
オブジェクト指向から逆行してんなあ
プロパティの状態が正しいことを検証するという目的を達成できれば良いんだよ
読む必要なんかないというのが正解
というかむしろ物理的な制約をいちいち外から確認しに行くバカがいるかよ
そんなものはそのオブジェクトが知ってればよろしい 断言するけどいつかチームの誰かバカがやらかして
こっちのプロパティではこういう制約なのに
あっちのプロパティでは同じ意味のはずなのに制約が違います
どっちが正しいのでしょうかという状況が必ず訪れる
こうなると可読性もクソもない書いてあることが矛盾しているという事態に陥る
これはDRYの原則に反するからこういうことが起こる
これを属性で回避するなら
MovieTitleAttributeのようなカスタム検証属性を作って使わなければならない
はっきりいって遠回りだしこうなると結局のところ検証属性の詳細も見えなくなる
属性プログラミングでオシャレ気取ってないでMovieTitleクラスを普通に作れってこった つまり自分で検証属性を用意すればいいってことですかね?
面倒くさいなぁ >>112
属性にこだわるならね
めんどくさいだろう
しかもプロパティがもしもなんらかの振る舞いを持った時に結局普通のクラスを作るんだぜ
タダでさえカスタム検証属性は書くのがめんどくさいのに
それで二度手間になるとなっちゃやってられんね 属性使ってるのは asp.net mvc のクライアント側とサーバ側の検証機能をフレームワークに作らせるためだろ
フレームワークがそういう機能持ってるからそうしてるだけだろう。
けちつけるところじゃない。 フレームワークに踊らされてるよね
楽をするためのフレームワークで手間増やしてるんだもの 手間増えてるのか?
サーバ側だけでなくクライアント側も属性つけるだけで自動でやってくれrjんだけど
自分で都度検証コード作る方が手間だと思うけど。
要件変わればクライアント側もサーバ側も書き換えないといけんし。 クラス化しておけばメソッドを呼び出すだけで自動でやってくれる
サーバーもクライアントも考え方は同じ
カスタム検証したいときに属性に乗っかった時の無駄にわかりにくい面倒な手続きもいらない
そしてタグがスマートになる
クライアントとサーバーがフレームワークで結合してると乗り換えめんどくさい てかDB上に文字長定義があるのに、それを手書きでコーディングしないとアカンの?
FWが勝手にカラム定義を取ってきてくれればいいのに EntityFrameworkのコードファーストなら
属性をもとにDbに制約つけてくれるでしょ >>121
そのモデルを直接使うのは推奨されてないでしょ?ViewModelにコピペするのがめんどくさいとかそのレベルの話じゃない? コピペするのはいいけど、仕様が変わった時に変更箇所をすべて書き換えなきゃならないのが面倒くさい
担当者が変わったりすると変更漏れが出てバグの温床にもなる 普段はDBのシステムテーブルから定義取ってきてバリデータ生成してるから、
手動コピペ必須はちょっとキッツイわ
EFって大変なんだね 既存のSQLServer以外に対応するならコピペ必須になる Aページでは必須、Bページではオプション扱いといった具合で
異なるページでvalidationが変わる場合も面倒じゃ?これはどうするの? >>126
ページごとにViewModelを使い分けるのはよく見るねえ 検証はDRYの原則が当てはまらないからめんどくさいのは仕方がない
それぞれ目的が違うし内容も違うから自動生成もできない
こればかりは地道にやるしかない .netcoreapp1.1でコンソールアプリ作るときにDLLを参照に追加したら、
ビルドは通るけど、実行時に見つからないってエラーでるのなんでだろう
.netframeworkのコンソールだと実行も問題ないです
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly "TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot
find the file specified.
dllは.netstandard1.6でほぼ空のコードをコンパイルしただけのもの。 なんでASP.NETって人気ないの?
ちょっと前までWindows専用だったから?
モノ自体はPHPとかRubyとかPythonとかJavaとかと比べてどうなの? Javaよりはるかにやりやすいよ
でもユーザー層がGUIバカばっかりでいきなりLinuxって言われてもって感じだろうね
Javaやってる連中はレガシー抱えて身動き取れないからJavaを引き続き使うだろうし
スクリプト系のウェブフレームワークはターゲットが違うな >>130
ASP.NETと.NET Standardの2.0が出てからだろね 普及期に入ったかな? UWPもそろそろ移行期だし、MSのオプソ、マルチプラットフォーム化が完成まぢか、、、 1台のホストに複数のサービス立てるって意味ある?
nginx xxx.xxx.xxx.xxx:80
asp.net core app localhost:5000
asp.net core app localhost:5001
asp.net core app localhost:5002 並列でDBContextにAddするとAggregateExceptionになるから
lockステートメント使うと思うんだけどあってる?
DBContext内部でEntity追加してるときに、他のEntityの追加処理が割り込んで
処理がおかしくなるからlockしてるって解釈してるんだけど記述がなくてモヤモヤしてる そもそもスレッド跨いでcontextを利用するのが非常識か。失礼 複数のValidationAttributeを複数のクラスで同じように使ってるんだが
ひとまとめにする方法を教えてくれないか?
//Login
[Display(Name = "Email")]
[Required]
[EmailAddress]
public string LoginEmail { get; set; }
//Account
[Display(Name = "Email")]
[Required]
[EmailAddress]
public string AccountEmail { get; set; }
↓
//Login
[MyEmail]
public string LoginEmail { get; set; }
//Account
[MyEmail]
public string AccountEmail { get; set; }
こんな感じにしたい
MyEmailの作り方がわからない 標準でできることだしその検証ロジックが頻繁に変わるとはおもえないし
それでいいんじゃね。
あえて余計なものいれると逆に保守コスト増えそうだけど。 いや、これは例だから。実際は違うんでひとまとめにしたい https://msdn.microsoft.com/ja-jp/library/cc668224(v=vs.100).aspx
DisplayAttribute は同じ名前空間にはあるけど実装が違うので無理。
[Display(Name = "Email")]
[MyEmail] >>142
ソース公開されてるんだから自分で書けば良い そういうのはコード生成した方がいいよ
属性は完全に失敗作 modelからserviceを取得するにはどうしたらいい? netstandardで.exe吐き出したいのだけどうまくいきません…
netcoreappの場合はruntimeidentifierを指定することでうまくいきました。
どなたかヒントor解説サイトを教えてください。
ちなみにvscodeとdotnetコマンドの組み合わせで使ってます。 >>151
.NET Standardは、あくまでもライブラリ用じゃないの? え、そうなの!?
実はilmerge使いたかったのだけどnetcoreappは対応していないらしかったのでnetstandardを試してみたのです。 core sdkってv2が出てるんだな。
v1と大きく違うの? >>156
APIが大きく拡張されて、Fullのframeworkから移行しやすくなってる せっかくLinuxでも使えるって謳ってるのに
MySqlのEntityFrameworkCoreが対応してないじゃん
ゴミだわ
一生WindowsのみでやってろよMS >>161
これがMySql使ってるやつの思考回路か
とりあえずプレリリースのでも使って問題があれば報告しろよ >>161
オープンソースなのに文句いうだけでなにも貢献しないのか
ゴミだわ >>164
.NET Core2.0リリース後に対応するって言ってるね PostgreSQLの方は1.0のリリース当初から対応してたはずだけど、この差は何なんだろう >>165
それ型周りにバグがあってゴミ
せめて使えるものを提示しろ >>172
うんにゃ、むしろEF CoreだともうModel Firstなんてないし ○次受けが多いほど退場率が早くなる。高くなる
直受けの50万 客:いつまでもうちにいていいよ
3次受けの50万(客は90万払ってる) 客:短期延長していい?
5次受けの50万(客は150万払ってる) 客:作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば3次から入場できるだろ?
高額をうたうフリーランスのサイトはだいたい5次から45万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3 = 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる Asp.Net Core & EntifyFrameworkCoreで発行されているSQLのクエリーを確認するにはどうすればいいでしょうか? >>175
生SQL確認したら負けじゃね?
なんのためにLinqで隠蔽してんのかって話になる
生SQLを見てチューニングするぐらいならDapperへの乗り換えを検討したほうがいい 正しいかどうか、高速かどうか
なんにせよ理想とするSQLがあって
EFの吐くSQLがそれに合致するか確認する
確認してあってなければLinqを変更して合致するように調整する
ってことでしょ
そんなんいちいち一手間かけないでSQL直接編集すればいいじゃん
目の前に患者がいるのに遠隔操作アームで手術するようなもどかしさを感じるね >>179
質問者はチューニングのためとは言ってない
思い込み激しすぎ >>180
チューニングに限った話じゃないよ
思い込んでるのはそっち
目的がなんにせよSQL見たいって時点でもうEFの意義を失うのだから
最初から生SQLでやったほうが良いんだよ >>181
EntityFrameworkを初めて使って、実際にどういうSQLに変換されているのか見てみたいだけって可能性すら考えられないの? >>181
じゃあなんでEFは生のSQL見れるようになってるの?
答えて? >>183
EF開発デバッグ用
本来EF利用者が使うものではない 宣伝: SQLプロバイダに依存せずAPIだけで使えます
実態: SQLをいちいちダンプして調べないとろくに使えません c#がどんどんc++化してるな
流れに乗ってtemplateも取り入れるべきだ コンパイラオプションでいいから?.をデフォルトにしてほしい
string? n = null;
var m = n.Substring(0, 5);
Assert(m == null);
こうした方が絶対便利 .net core 2.0とvs2017community を使っています。
自分で作ったプロジェクト内のクラスAを、別のソリューションのプロジェクトから参照して、
使いたいんですができるでしょうか。
クラスAは、Nugetで取得したパッケージに依存しています。 >>193
レスありがとうございます。
参考になるサイトがあれば教えてほしいです。 >>194
同じソリューション内に配置することができないなら、自分で作ったライブラリをNuGetパッケージ化して、それを参照すればいいんじゃない? >>195
ありがとうございます。
ソリューションのフォルダの中にあるbinとかobjとかのdllを参照して、
usingで名前空間をセットしたんですが、エラーになりました。
InvalidOperationException: Cannot find compilation library location for package MYClassLibrary'
NuGetにアップロードしないとダメっぽいですか。
以前の.Netでは簡単にできていたのになあ。 >>196
いろいろと間違いすぎててフォローできん… >>197-198
ぐぐってみて、参照先プロジェクトフォルダ内にあるcsprojというファイルのパスを、
参照元のcsprojに指定しました。
<ProjectReference Include という項目に設定しました。
参照元のプロジェクトを起動させるのですが、
必要な様々なパッケージ(デスクトップ開発とか、たくさん)が足りないので、
それらをインストールするまではロードしませんというエラーになりました。
しかし参照元も、参照先プロジェクトも、同じ環境でそういうエラーなく動作します。
プロジェクトを参照するには必要なパッケージがあるということなんでしょうか。
それなら、Linuxなどで動作させられないのではないかと心配です。
.net coreオンリーで組みたいので。 >>199
dotnet add reference コマンドを管理者プロンプトで動作させました。
ローカル パッケージ キャッシュを最初に設定し、復元速度を向上させ、
オフライン アクセスを可能にするため、コマンドを実行しています。
このコマンドは 1 回だけ実行され、完了までに最大 1 分かかる場合があります。
その後、うまくプロジェクトが起動してくれましたが、
デバッグが通らなくなりました。
ClassLibrary.csproj' のプロジェクト情報が見つかりません。プロジェクト ファイルが無効であるか、復元に必要なターゲットが見つからない可能性があります
参照先プロジェクトでは、‘Nugetをつかって外部ライブラリを使用しているからなんでしょうか。 ■ このスレッドは過去ログ倉庫に格納されています