ふらっと C#,C♯,C#(初心者用) Part145
レス数が900を超えています。1000を超えると表示できなくなるよ。
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと(1行分は消えて表示されない為)
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C#(初心者用) Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C#相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - @IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET .NET Tips
https://dobon.net/vb/dotnet/index.html
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>838
まじで日本語の理解力がなさすぎ
(引っ込みつかなくなってるだけかも知れんがw)
> うん、使わなくてよくね?
という君の意見はどうでもいい
Linqは>>811が書いてる通り
> LINQでつなげる場合はLINQメソッドの戻り値を意識しながらつなげるわけだから、話が違うじゃん
ってことな >>839
いや、だからそんなことわかりきってるよw
807で君が言った内容に対して表記が同じとしか言ってない
ちゃんと機能が異なることを追記した上で同じ表記だね、って言っただけでしょ?
それに対して延々と同じ内容で煽り続けてるんだよ?
linqは意味が違うよっていう808からの始まった内容に対してlinqは意味が違う!馬鹿なの?って
もっかい始めの方からレス内容確認したほうが良いよ
言葉尻捕まえて煽るだけで引っ込みつかなくなってるのはたぶん君の方だよ もう堂々巡りにして引き分けに持ち込もうと必死だな
Linqならメソッドチェーンにする意味があるから
> tweenerみたいな設定が多いもの
と一緒にされても困るって何度書いても同じこと書いてくるんだろうなw 機能の話から表記の話なってまた機能の話に戻す
表記の話のときに表記が同じ例を提示すると機能が違うんだから同じにすんな!
ってそりゃそうですよね、機能は違うってみんな言ってますもん
機能が同じだなんてレスどこにありました? 804:機能の話
807:機能から発展した表記の話
808:表記の類似例の提示
811:機能ちげーじゃんというツッコミ
813:そうだよ機能は違うよという返し
ここから延々、表記の類似例に対して機能が違うじゃんというツッコミ
811は807とは違う人だけどね
807でも機能の話をしてたと言うなら俺の読解力が悪かった
表記の話であることを明確にするために808に意味合いが異なると注記したつもりではあった
今見返しても表記に関しての話題転換にしか見えないけど ゴミのような時間の使い方をしている人らとはどっこいどっこいって感じよ まだ言ってるのかよw
> 機能が違うからダメと言うより必要もないのにチェインメソッド使わなくても良くね?
> って話な
って書いてあるのに「機能が違う」を連呼するしかない脳無し乙 >>1
>なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
>C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
ID真っ赤にしている人はコレ100回読んでね お互い口汚く罵るのはやめよう。どちらも有益な情報を持ち込み、スレに貢献してると思うよ。
>>844
機能と表記の 2 観点からの考察ありがとう。君の主張は首尾一貫していて妥当だと思うよ。
私は return this 完全否定はしないけどね。
>>842
tweener なるものが何か知らないのだが、設定の手数の観点で C# と比較できるものではないということはわかった。ありがとう。
私が return this を時折使う理由も設定の手数あたりにあるかもしれないと思った。
変数宣言&インスタンス初期化を “本処理とは分けて” ワンライナーで書きたいのだが、初期化の手数が多いときに return this 使うよ。
var a = new ClassA().Init1().Init2().Init3();
var b = new ClassB().Init(a);
// a, b, その他の変数を用いた本処理
という感じで。
初期化と本処理をごちゃ混ぜに書くと本処理の本質が見えづらくなるため好きではないし、if, for などで新しいブロックが出てくるわけでもないのにコンテクストの途中で新規変数宣言するのも好きではない。純粋に表記スタイルの (好みの) 話。 まあLINQはさておき
前者と後者じゃ後者のほうがスッキリして見える場合もあるんじゃないかなとは思う
hoge.foo();
hoge.bar();
hoge.baz();
hoge.quz();
hoge
.foo()
.bar()
.baz()
.quz();
セミコロン必須の言語やif文とは相性そんなに良くないけどさ >>850
tweenerはたぶんゲーム分野とかで使うことが多いと思うけど表示物のアニメーション制御に使うようなライブラリを指して言った
最近はweb系もアニメーションには富んでるからそっちにも似たようなものはある
表示物のx座標をaからbにc秒かけて移動させる、そのときd秒遅れてアニメーションを開始して終了後にe関数を呼ぶ
みたいな設定をするのに使う c#の先祖に当たるdelphiではwithがあったがC#で亡くなった まあ罵倒は見てて見苦しいねw
thisを返す手法に違和感を感じる人(自分もその一人)が多いのは、
(1) シグジェチャだけではメソッドが返す値がthisなのか別のインスタンスなのか分からない
(2) チェーンさせる目的でthisを返すのは意味論(メソッド名はそのメソッドの機能を表現する)を破壊する
こんなところか。
本来は必用なら言語レベルで実現すべき機能なんだろうね。
でもC#erってVBのWithブロックには否定的な人が多かったよな 相談させてください。
以下のようなクラスを作りたいと考えています。
class MyStaticClass1
{
static double HighCostMethod() { ... }
public static double X = Math.Sign(HighCostMethod());
public static double Y = Math.Abs(HighCostMethod());
}
しかし高コストな HighCostMethod を2回も呼びだすのは無駄なので
以下のように改良しました。
class MyStaticClass2
{
static double HighCostMethod() { ... }
public static double X, Y;
static MyStaticClass2()
{
var v = HighCostMethod();
X = Math.Sign(v);
Y = Math.Abs(v);
}
}
ところがこのコードは規則 CA1810 に違反すると警告が表示されました。
静的コンストラクターにはパフォーマンス上の欠点があるようなのです。
【CA1810 参照型の静的フィールドをインラインで初期化します - Visual Studio Microsoft Docs】
https://docs.microsoft.com/ja-jp/visualstudio/code-quality/ca1810?view=vs-2019
(続く) (続き)
そこでさらに次のように改良したところ、無事警告は表示されなくなりました。
class MyStaticClass3
{
static double HighCostMethod() { ... }
public static double X = Initialiser.Instance.X;
public static double Y = Initialiser.Instance.Y;
class Initialiser
{
public static Initialiser Instance = new Initialiser();
public double X, Y;
Initialiser()
{
var v = HighCostMethod();
X = Math.Sign(v);
Y = Math.Abs(v);
}
}
}
ただ、クラス初期化時のパフォーマンス上の問題を解消するために
さらに別のクラスを定義するのは本末転倒な気もします。
私のアプローチは正しいのでしょうか。
それとも素直に CA1810 の警告表示を抑制すべきでしょうか。
もしくは、別のもっとスマートな解決策があるのでしょうか。
アドバイス等をいただけると嬉しく思います。よろしくお願いいたします。 俺自身もthis返す設計に否定的で813で明確に表明してるんだけどねw
850の初期化の例みたいなのもC#ではメソッドに引数名を指定して呼び出すことができる機能があるからそれで事足りる
引数の数が多くなったりオプション引数使えば更に長くなったり呼び出し側も見た目はスマートとは言えないような書き方になったりするんで多用は避けたいところだけど局所的な利用なら無しでは無い気もする
まぁ設定用の構造体作って渡すとかjson等をシリアライズしたものを渡すとかのほうがいいんじゃない?とは思う >>856
>高コストな HighCostMethod を2回も呼びだすのは無駄なので
典型的なシングルトン。
データベースマネージャーとか、何かを管理するクラスは、基本的に1回しか実行しない
init( ) みたいな、特別な関数でしかnew できない。
通常の方法では、newできないように、エラーになるように作る >>857
HighCostMethod()の結果をキャッシュする
キャッシュがあればそれを使う、なければHighCostMethod()を呼んでキャッシュに入れてから値を返す >>856
private static double Cache = HighCostMethod();
public static double X = Math.Sign(Cache);
public static double Y = Math.Abs(Cache);
みたいに一旦結果を受けるものを作れば回避できそう >>859
レスありがとうございます。
おっしゃるとおり、シングルトンを使えば問題は解決するだろうと考えて
作成したのが MyStaticClass3 なのですが、
MyStaticClass3 が MyStaticClass2 よりも
パフォーマンス的に優れていると考えられなくて
質問させていただきました。
> init( ) みたいな、特別な関数でしかnew できない。
> 通常の方法では、newできないように、エラーになるように作る
ここで説明していただいているお話と
MyStaticClass3 の中身の違いがよく理解できていないので
詳しく教えていただけないでしょうか。
よろしくお願いいたします。
>>860
レスありがとうございます。
HighCostMethod()の結果をキャッシュするための装置として
MyStaticClass3.Initializer を作ったつもりなのですが、
改良点などがあればご指摘いただけると幸いです。
よろしくお願いいたします。
>>861
なるほど!レスありがとうございます。
ただ、一時的に値を保持するためにフィールドを使うのは
少し抵抗があるきもするのですが、よく使われる手法なのでしょうか。
また、一つのクラスを複数ファイルに分けて記述できることを考えると、
フィールドの初期化は必ず上から順に行われることが
保証されているのかということについても少し不安があるのですが、
もし何か参考資料などをご存知なら教えていただけると嬉しく思います。
よろしくお願いいたします。 >>851
そう、そう言う風に純粋に見た目の話をしてるのにチェインメソッドにするしかない(まあ一旦変数に受けりゃいいんだけど流石にそれはねぇ)Linqを出されてもねぇ
Linqをバカにされたとでも思ったのかな?
それはさておき、たしかに同じ変数を何度も書かされるのはなんとなく冗長な感じがするからWith文みたいなのが欲しいのは理解できる
そのうちオブジェクト初期化子でメソッドが呼び出せるようになったりして
var a = new ClassA().Init1().Init2().Init3();
var b = new ClassB().Init(a);
↓
var b = new ClassB(){
Init(new ClassA(){ Init1(), Init2(), Init3() })
}; VS2015だとCA1810 なんか出ないなw
出るとしても警告を抑止して問題ないケースだと思うけど stringのreplaceとか別のインスタンスじゃん
こういうのと仕様が違うの作っちゃうの嫌だな
こういうのは多数派に合わせる感じで >>862
「一つのクラスを複数ファイルに分けて記述できること」はpartial classを指していると思うんだけど、その場合はちょっと分からん
ただpartialでない普通のクラスの場合は、初期化は記述順(上から順)に行われることが保証されている
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#fields
> The static field variable initializers of a class correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration これはOKみたい。
static double x;
static double y =
(
(Func<double>)
(
() =>
{
var v = HighCostMethod();
x = Math.Sign(v);
return Math.Abs(v);
}
)
)();
もちろん俺ならこんなことしないw
素直に警告無視or抑止するのが一番いい。
無駄なことして可読性落とすなんて愚の骨頂 >>864
情報どうもありがとうございます。
Visual Studio のバージョンに依存する話だったのですね。
私は Visual Studio 2019 (Version 16.3.10) を使っています。
情報が後出しになってしまい失礼いたしました。
> 出るとしても警告を抑止して問題ないケースだと思うけど
ご意見ありがとうございます。 >>856 に貼り付けたリンクの先にも
「パフォーマンスが問題にならない場合は、このルールの警告を抑制しても安全です。」
と書いてありますし、やはり抑制が最善の方法であるような気もしてきました。
>>865
> プロパティ
アドバイスどうもありがとうございます。
string.Empty の様に、プロパティである必要がないものは
フィールドにしたほうがパフォーマンス的に有利かと思って
そのようにしていたのですが、確かにプロパティが一番真っ当ですね。
> Lazy<T>
ありがとうございます。ただ、私の考える限り以下のような方法しが思いつかず、
だったら >>861 に書いていただいたもので良いのではと思ってしまうのですが、
もし Lazy<T> を使った別の方法があれば詳しく教えていただけると嬉しく思います。
static Lazy<double> Cache = new Lazy<double>(HighCostMethod);
public static double X = Math.Sign(Cache.Value);
public static double Y = Math.Abs(Cache.Value); >>867
おお!情報どうもありがとうございます。大変勉強になります。
そうであるなら、Cache のフィールドが残ることが気にならないか、
もしくは Cache も後々使うなら >>861 に書いていただいた方法が
最善になりそうですね。
>>864
なるほどw 警告も万能ではないとういことですね。
説得力のある面白い例を示していただきどうもありがとうございます。 >>868
そのコードだとyにアクセスせずxにだけアクセスしたら初期値の0のままだぞ >>869
>>865の一つ目のリンク(.NET Fiddle)がLazy<T>使ったサンプルだよ >>871
CA1810のページによると、staticフィールドの初期化はいずれかのstaticフィールドに
最初にアクセスされる前に行われるとなってるから、それはないのでは?
知らんけど >>872
サンプルを書いてくださっていたのですね。大変失礼いたしました。
ただ、やはり Lazy<T> を使うメリットが理解できずにいます。
MyStatic が初期化される時点で _highCost が初期化されて、
その後すぐに _highCost.Value が呼び出されるのであれば、
>>861 に書いていただいた方法で十分な気がするのです。
>>873
おっしゃるとおりだとおもいます。
ところで少し考えてみて、場合によっては冗談ではなく
public static double X, Y = InitializeYAndX();
static double InitializeYAndX()
{
var v = HighCostMethod();
X = Math.Sign(v);
return Math.Abs(v);
}
みたいな書き方が選択肢になり得ることもあるような気がしてきました。
もしくは、実際にはフィールドは readonly にしたい場合が多いと思うので
public static readonly double X, Y = InitializeYAndX(out X);
static double InitializeYAndX(out double x)
{
var v = HighCostMethod();
x = Math.Sign(v);
return Math.Abs(v);
}
のような感じとか。 >>874
個人的に警告を回避するために普段しない書き方をするのは違うと思う
警告の内容を理解し、それが今回のケースでは問題ないと判断できるなら遠慮なく警告を抑制していいと思う
プログラム起動時に自動的に初期化されるstaticとプログラマが初期化タイミングを制御できるsingleton
起動コストが問題なくてstaticが妥当なら警告抑制を選択するかな >>874
LowCostMethodも追加してみた
https://dotnetfiddle.net/Be6wMy
名前の通りLazy LoadingとかLazy Initializationとかいうのをするためのもので
必要になった時に初期化されてなければ初期化して、初期化済みなら初期化済みの値を使う
MyStaticクラスが初期化される時点で_highCostが初期化されるわけではない
getプロパティで
if ( cache == null ) { cache = HighCostMethod(); }
return cache;
するのと意味的には同じでdefaultでthread-safe
詳しくは>>862の2つ目のリンクに書いてある
あともし他人も使うコードなら潜在的に高コストな処理は
フィールドやプロパティじゃなくメソッドにしといたほうが無難 >>875
> 個人的に警告を回避するために普段しない書き方をするのは違うと思う
> 警告の内容を理解し、それが今回のケースでは問題ないと判断できるなら遠慮なく警告を抑制していいと思う
アドバイスどうもありがとうございます。確かにおっしゃるとおりですね。
この考え方で、警告を抑制する方向で行こうと思います。
> プログラム起動時に自動的に初期化されるstaticとプログラマが初期化タイミングを制御できるsingleton
static はプログラム起動時に初期化されるんでしたっけ?
ただいずれにしても、コストが非常に高い場合は
明示的に初期化のタイミングを指定できるように気をつけたいと思います。
>>876
詳しいご説明ありがとうございます。
「MyStatic が初期化される時点で _highCost が初期化されて」
という表現は正しくありませんでした。失礼いたしました。
ただ、お書きいただいたコードでは
private static readonly Lazy<double> _highCost = new Lazy<double>(HighCostMethod);
の直後に
public static double X = Math.Sin(_highCost.Value);
public static double Y = Math.Abs(_highCost.Value);
が実行されるので、例えば
private static readonly double _highCost = HighCostMethod();
と
public static double X = Math.Sin(_highCost);
public static double Y = Math.Abs(_highCost);
に書き換えても同じではないでしょうか?
> あともし他人も使うコードなら潜在的に高コストな処理は
> フィールドやプロパティじゃなくメソッドにしといたほうが無難
アドバイスどうもありがとうございます。言われてみて、確かにそのとおりだと思いました。
コストの高さに応じて適切な書き方が選択できるように勉強したいと思います。 もう誰かとっくに書いてるだろうけど、やっぱり本来は重くなる可能性があるなら
フィールドやプロパティーじゃなくてメソッドにすべきなんだろうね。知らんけど
static double _x, _y;
static Action InitializeXY = () =>
{
var v = HighCostMethod();
_x = Math.Sign(v);
_y = Math.Abs(v); ;
InitializeXY = null;
};
public static double GetX()
{
InitializeXY?.Invoke();
return _x;
} なんかこう、せっかくの言語仕様を活かしきれてないような
もったいなさがあるよね 原則としてはgetterでは値の取得と通知しかしてはならない
これはC#に限った話ではなくオブジェクト指向の大原則の一つ 大原則?
オブジェクト指向の原理主義的にはそもそもgetterを作るべきではないんだよ
getterを使うのは上司がタバコを吸いたいときに不器用な部下にしびれを切らして「お前、もういいからお前のライター寄越せ」
と言っているようなもので、オブジェクトから本来担うべき責務を剥ぎ取ってしまっている
火をつけろと命令を投げっぱなしにしておけば勝手に火をつけてくれるのが本来のオブジェクト指向の姿 昔の人は言いました「100人のプログラマーがいたら100通りのオブジェクト指向がある」 なるほど
博士が100人いる村につながる胸熱展開ですね 消すの意味次第
抑制も含むなら消してる
抑制は含まないなら消してない vs 2019でenumをuintで作ったらint32にしろって警告された
win32api用なんだけど使用時にキャストしろという事か フォルダファイルの情報集めてデータベース作りたいんですけど
データベースの種類って何がいいのかな?
3万件ぐらいのレコード、外部に持っていくこともしない
よろちしおねがいします 何がしたいのかによるよね
ぶっちゃけ外にださないんだったらcsvですらいいんじゃね?って気もするけど linuxにはlocateコマンドと言うものがあってファイルを高速に検索できる
これはただあらかじめフルパスのファイル名を全部取っておいて一つのテキストファイルにまとめてあるだけ
用途次第で最適な方法は異なる フルパスそのままじゃなくて差分のようなテキストファイルを作っていたような気もする >>893
Redisなんてゆうデータベースあるんですね、一般的なのかな
さんくすしらべてみます
>>895
サンクスsqliteよく使われてますよね昔から
今でも普通に使われてるのかな?
>>894>>896-897
何がしたいのかとゆうと、外付けHDDの中身を書き出したい的な事がしたいのです
高性能なフリーウェアがあるとしても、自分でつくりたいのれす いや、知りたいのはその書き出したファイル情報をどうしたいのか?なんだけど…
自分で作りたいというのが勉強を兼ねてるならsqliteとかでひとまず慣れるのが良いんじゃない? 教会作るのか扉作ってるのか木を切ってるのかっつー話よな
それはさておき
お手軽に使えるのはSQLiteでライブラリやマッパーも豊富
redisは高速でwebクラウド周りでは結構ちやほやされた
けどRDBとNoSQLの区別付いてるかは心配やな
外付けHDDの中身…か… テキストファイルにファイル名ずらっと並べて終わりだろう >>900
さんくす、SQlite?そんなの古くて誰も使ってないよ?みたいな状態が怖い
>>901
さんくす、とりあえず椅子を作りたい、用途に多少合わなくても使えるから
簡単な検索、重複ファイルの処理とか?
速度は遅くていいので、簡単で扱いやすいのがいいでつね
RDBで作ろうとおもってます
>>902
そんな感じになりそう、さすがにテキストファイルは作らないけど
sqlite使ってみようと思いますが、Microsoft SQL Serverってどうなんでしょう?
定番なんでしょうか?それとも難しいとか使いにくいとか >>903
sqliteはローカルで閉じたお手軽DBとしてはまだまだ現役よ。ローカルDBのデファクトスタンダードと言っていいぐらい。
クライアントサーバのようなシステム作りたいなら不向きだけど。 SQL ServerとかそれこそWinのクラサバでしか使われてない無価値な技術だぞ sqliteは組み込みDBではメジャーだろ。androidアプリの標準ローカルDBがsqliteだし。iosのcoredbだって内部はsqlite使ってるだろ?
モバイルアプリでsqlite使われまくりだろ。
まぁ、最近はrealmだのあるが sqliteはChromeとかfirefoxでも使ってるはず >>903
win環境ならSQL Serverは最有力選択肢だよ
C#前提ならVisualStudioとも統合されてるし、簡単に扱えるので取り回しもしやすくて情報も多い
気になるのはやろうとしてることに対して、若干大げさな構成かなという点かな
RDBの経験積みたいのが目的に含まれるなら全然アリよ インストールとかもSQLServerのインストールと設定込みになるから大げさだよ
インストール先でSQLserverの管理も必要になる(セキュリティーホールに対するアップデートなど)
sqliteがいいと思うよ プロダクト目的なSQLite
勉強目的ならSQLServerっつーことで >>904
さんくすです、現役なら今から勉強しても無駄にはならなそうですね
>>905
Microsoftはたまに、それ誰得よってのがあるから怖い
>>906
さんくす、androidに使われてたらしばらく安泰でつね
>>908
ちょと調べてみたけど、きびしい、頭の片隅に
>>910,912
さんくす、SQLServerも間違ってはいないのですね
DB使うまでもなくオーバスペックっぽいけど、練習になるから
>911
導入がメンドイのと保守もいると、さんくすね
>909
firefoxで使ってるのみました、でもFFは設計古いままきてるからどうなのかなって
>913
VisualStudioにsqliteいれといてくれたらいいのにね
みなさんさんくす、現在のDBの立ち位置がわかって、方向性がだいたい決まりました
まずはsqlite導入してみようかな SQLiteって導入するほどのもんでもない
っていうか導入とかせんでも使えるし nugetで簡単にプロジェクト追加できるからVisual Studioに付属していないという批判はお門違い >>917
まあこういう文章だと語尾がしねに読めちゃうのはしょうがないしね 「〜だしね」からの「しねとは何だ!」ってのはいつものお約束だろw
むしろ愛を感じるわ。 >>914
> VisualStudioにsqliteいれといてくれたらいいのにね
2019は知らんけど2017はVisual Studioのインストール時にSQL-Server LocalDBを入れるかどうかを聞いてきたような気がする
LocalDBは外部からの接続できないだけで中身はほとんどSQL-Server
Visual Studioからテーブル開いてデータを弄ることもできるしそこそこ便利よ >>923
使いたいときはentityframeworkっていう似たようなものを被せて使います >>922
まじでっ、2017入ってるんだけど記憶にないお
スキップしたんだろうな、今からいれてみるサンクスね >>915-918
nugetも入れたほうがいいのかお genericsの〈T〉のTって動的に入れるのは無理?
System.Typeはわかってるんだが >>928
Type.MakeGenericType >>927
nugetを入れると言う以前にVS使ってソリューションて作るとすぐ使える状態にあるし
SQLiteを始めとして外部ライブラリを導入するならnuget使うのはc#では基本ツールと言えるので、使えたほうが良い
パッケージ管理にnugetが最適かは置いておくとして sqliteやるとして、Dapperを使うかEF使うかは意見が分かれるところだね
ついでにSQLから始めるってことでDapperをお薦めしますが
EFはSQLを知らなくてもなんとかなるが、そのうち壁にぶち当たるだろうからね SQLiteとEFの組み合わせはテスト専用だ
EFはサーバー用のフレームワークなのでSQLiteを使うようなスタンドアロンなアプリで使用されることは基本的にないし、
EFなんか被せたら軽量なSQLiteが台無し SQL-Server Local DB って MSDE のこととちゃうんけ MSDEつーか、SQL Server Expressだっけかな レス数が900を超えています。1000を超えると表示できなくなるよ。