C# 초보 - 개발환경 문의드립니다.

⁉️ 프로그래밍 언어 Q&A C# Q&A
1

안녕하세요. 조언을 얻고자 글을 작성하였습니다.

C# / SQLite / Dapper / NLOG / WPF 로 프로젝트를 진행 예정에 있습니다.

  1. 닷넷 (닷넷 프레임워크) 버전 선정 기준
    1.1] 개발시 어떤 버전을 타겟으로 잡으시는지 기준을 알고 싶고, 버전도 어느 버전으로 세팅하는게 적당한지 조언을 구하고자 합니다.
    1.2] window 10 / 11 설치시 기본으로 설치되는 닷넷 프레임워크 버전이 정해져있는지도 문의 드립니다.

    1.3] 주변에 닷넷 개발하시는 분들이 없어서, .net Framework 4.8 로 진행할까 하는데, 이 부분에 대한 의견도 조언을 듣고 싶습니다.

  2. 낮은 버전의 닷넷 버전으로 개발된 App 은 상위 버전의 닷넷 버전에서 정상적으로 실행이 되는지에 대한 문의입니다.
    ex) .net framework 4.8 로 개발이 된 App 은 설치된 PC 에 .net framework 4.8 이 존재하지 않고, .net의 7,8 버전이 설치된 PC에서도 정상 동작 하는가…? .(net 은 .net framework 를 포함하여 버전업이 되는걸로 인터넷 서칭을 통해 이해했습니다.)

  3. SQLite DB 에 SQL 쿼리를 실행 시, ORM 으로 Dapper 적용하여, 바인딩된 쿼리를
    NLog 로 로그를 출력하고자 하는데, 그 방법을 찾지 못하였습니다.
    불가능한건지, 방법이 있는지도 문의 드립니다.
    지금으로서는 SQL 쿼리가 저장되어있는 string 을 불러와서 바인딩처리되는 변수를 replace 하여 log.info 를 해야하나 정도로 밖에 생각을 못하고 있습니다.

긴 글 읽어주셔서 감사합니다.~~

4개의 좋아요
2
  1. 닷넷은 지원기한이 있어 작년 11월에 나온 8버젼으로 가면 좋을듯 합니다…LTS니까요…
    기본으로 설치가 되는지는 기억이 안나는데, 코어 3.1부터 사용을 했었는데, 별도로 설치 했었습니다…
    2.버젼 호환은 될겁니다.~ 설치된거 보면 버젼별로 다 설치 되어 있더라구요…

저도 초보라 틀린내용이 있을수도 있으니, 고수님들이 검증 부탁드려요~

4개의 좋아요
3

Window 10의 경우는

image

.Net Framework 4.8이 기본으로 설치되어 있는거같아요~

아 그리고 닷넷코어의 경우에는
해당 PC에 .net Core 없을 경우 설치되어있지 않다는 팝업과 함께 노출되고 확인을 클릭하면 해당 사이트로 연결되어 다운받을 수 있게 처리됩니다.

.net core 에서 .net standard 2.0이상 으로 되어있는 라이브러리들은 호환성은 미치도록 좋습니다!

4개의 좋아요
5

감사합니다!

3개의 좋아요
6

최신 .net8 을 추천드립니다.

3개의 좋아요
7

유지보수도 아니고 첫삽부터 레거시에 표류하실 필요가 없지 않을까 합니다. 절대 비추입니다.

1.1] 무조건 최신입니다. 닷넷 발전속도를 보면 지금 중간을 잡을 여유도 이유도 없습니다.
1.2] -
1.3] 최신 닷넷프레임워크는 레거시프로젝트를 지원하기위한 산소호흡기입니다. 연명할뿐 미래가 없습니다.

2] 결국 버전별로 각각 따로 깔게될거같네요,
개발단에서의 호환성을 말씀드리자면, 상위 마이그레이션에 따른 호환성문제는 그다지 격어본적 없어 괜찮을것같습니다만. 어차피 상위호환성을 염두하고계신다면 그냥 이미 있는 상위부터 시작하는게 맞지않을지 싶습니다.

3] 그냥 나온데이터를 순차적으로 출력하면 되는게 아닌지? 질문을 제대로 이해한건지는 모르겟네요

+] 회사의 강요가 있다거나, 당장 적은 R&D로 빠르게 프로토타이핑 할수있는 스택으로 위와같이 선정하신거라면 무난하지만, 개발의 가장 말단 기반으로 박아두기엔 너무 미래가 없는 스택입니다.

WPF : 개인적으로 GUI프레임워크는 어디에도 멀쩡한 답이 없다고 생각합니다.
중요한건 차후를 위해 프레임워크와 비즈니스로직을 꼭 분리시켜야할것입니다.

NLOG : 그냥 응용프로그램 굴러가는거 확인만 하는용도라면 아무렴 상관없을듯합니다.

Dapper : 당장 쉽고편할수는 있지만, 가장 비추합니다. 쿼리문자열관리도 문제지만 라이브러리의 구현방식부터도 리플렉션을 넘어 다이나믹코드가 난무합니다. 현 닷넷의 발전방향과 완전히 대치되는 가장 가망이 없는 스택입니다.

저라면 일단 GUI는 BlazorServer웹앱으로 만들거나, 급하면 버릴작정으로 WinForm으로 기워내지 않을까 싶네요.
SQLite, NLog는 일단 쓰되 의존성주입 패턴으로 최대한 적은 공수로 교체가 가능하게 만들수있습니다.
EFCore는 어쨋든 같은 MS자식이니까 믿고쓰는부분이 크고요
닷넷 런타임이 필요없게 하고싶으면 도커이미지나 자체포함빌드로 배포하고,
프로그램 용량을 감안해야한다면
닷넷프레임워크의 윈도우에대한 강한의존성을 활용할것이 아니라
처음부터 빌드Trimming을 쓸수있도록 감안하여 개발하셔야 할것입니다.

6개의 좋아요
8

Dapper에 대해서는 이견이 있는데요.

결국 ORM을 쓰더라도 SQL이 어떻게 생성되는지 다시 확인하는 작업이 필요한데… 성능도 느려서

차라리 uORM인 Dapper를 쓰는게 더 구체적이고 명시적이죠.

DB를 추상화 한다고 하지만… 소프트웨어 라이프 사이클중 DB 변경은 거의 불가능

Dapper도 써보고 EF Core도 써보고 CQRS에 대해 생각도 해보고 DB지향 SI 코딩도 해보고 전지전능한 오라클 지향 코딩도 해보고 요즘 snowflake로 하는데 Dapper 씁니다 ㅎㅎ EF Core로는 연결도 안됨

5개의 좋아요
9

SQLite 관련 패키지가 여러개가 있어서… 정확히 뭘 쓰시는지는 모르겠지만,
Trace, Hook 관련 단어 위주로 검색을 해보신다면 원하시는 걸 찾으실 수 있을 것 같습니다.
방법은 있는걸로 알고 있습니다. :smile:

그리고 프레임웍, 개발툴 등을 고려하실땐 혼자 개발하는 것인지, 팀원들의 참여도, 프로젝트의 중요도, 유지보수가 중요하게 생각되는 것인가, 내가 자신있는 툴로 개발하는 것인가… 등등을 고려해야 할 것 같습니다.

4.x 프레임웍을 가장 잘 하시고, 혼자서 개발하셔야 하는 상황이라면 그걸로 진행하시는게 일을 깔끔하게 끝낼 수 있는 방법이 되는 수도 있다고 봅니다.

3개의 좋아요
10

공감합니다.
Dapper가 EF core 보다 나은 점은 빠르다는 점 뿐인데, 사실 그 속도의 차이는 쿼리 자체의 복잡성도 한 몫한다고 봅니다.

동일한 DB 작업을 위해, 일반 사용자가 작성한 생 쿼리와 EF Core 가 생성한 쿼리는 아무래도 품질 차이가 있겠죠. 데이터 베이스 제작자들이 간편한 쿼리를 몰라서 복잡하게 만들지는 않았겠죠.

더군다나, EF Core 가 버전업되면서, 쿼리의 성능도 개선될 것이기 때문에, 개발자가 쿼리 능력을 높이기 위한 투자를 하지 않아도 되죠.

6개의 좋아요
11

여러 의견 감사드립니다
여전히 판단은 어렵고 귀가 앒아지긴 하네요^^

2개의 좋아요
12

네 추상화된 환경에 개발을 의탁해 DBMS나 쿼리를 의식하지않고 프로젝트를 꾸려나간다는건 꿈에가까운얘기고, 그저 의탁을 잘하기위해서 알아둬야할 개념도 더럽게많으니 그냥 ADO.NET의 번거로운부분만 싹 해치워주는 Dapper가 훨씬 편할수는 있는데요,

제가짚으려는부분은 Dapper라는게 지금, 많은거바라지도 않고 그냥 임의로 미리 구현해둔함수가지고 코드 줄수나 줄여주는정도의 편의를 제공받기위해 불필요한 대가를 치뤄야하는 라이브러리라는것입니다.

라이브러리 연식이 오래되다보니 아마 도입할 당시엔 최신 고급기술이었을법한 리플렉션, 다이나믹을 적극 활용하여 기능들이 구현되있는데요,
지금에와서보면 요것들이 코드를 난독화하고, 실행해보기전에 동작을 예측할 수 없으며, 일단 돌리면서도 뭐가 어떻게 돌아가는건지 모르게만드는 코드 품질과 프로그램 신뢰성을 저하시키는 주범들입니다.

지금껏 그정도는 감안해서 다들 써왓다지만, 현 닷넷의 방향성이 기존 동적코드들을 전부 소스제너레이터로 대체하여 컴파일시점의 검증과 런타임디버깅, 빌드Trimming 등이 지원 될 수 있도록 바꿔나가고있는데, Dapper는 이러한 혜택을 아무것도 못받습니다. 다이나믹코드가 기능구현에 필수불가결한 피쳐를 가지고있는것도 아닙니다. 아직 마땅한 대안이 없기는 하나, 이 구형의 라이브러리를 앞으로 계속 의존하기엔 무리가 있으며, 근본부터 다시만들어져야하는 라이브러리라 생각합니다.

4개의 좋아요
13

네. 그렇다고 해도 대체제가 없는 상황에서 일방적으로 하지 말라고 하는건 아닌거 같아요.

오픈소스의 지속가능한 개발이라는 것이 끝나는 시점에서 MS가 중요한 건 뒷전이고 자신들의 성과 위주로 Aspire나 만드는 걸 보면… C#이 한동안은 제자리 걸음 할거란 생각이 요즘 듭니다.

maui나 blazor, asp.net core의 하다못해 minimal api에 json 역직렬화 null 처리 등 고쳐야 할게 산더미인데 MS 스스로 선택과 집중을 못하는 상황이다 보니 미래가 안보이네요.

4개의 좋아요
14

dapper를 쓰지말고 ef core로 하라고 하시는건 시샵이라는 언어에 모든 서비스를 강제하는겁니다.

하다보면 자바도 붙을수 있고, 파이썬, node.js 등등 여러 언어 및 프레임워크가 붙을수 있고
하다가 나중에 DBA가 들어올수도 있는겁니다.

개발자가 DB까지 다 하는 이 상황자체가 열악한 상황인데 그걸 ef core가 만사 다 처리해줄꺼라고 생각하면 안됩니다.

dapper가 나오고 사람들이 많이 쓰는 이유는 다 있습니다.

DB는 DB단으로 분리해야합니다.
그걸 프레임워크단으로 다 종속시켜버리면 나중에 분리하거나 다른 문제가 생기면 여기에 묶여있는 문제로 인해 해결이 더 어려워질수도 있습니다.

ef core가 만들어주는 sp보다 DBA가 만들어주거나 튜닝해주는게 더 좋을수 있고 그게 더 좋을 확율이 큽니다. 그리고 책임도 분리 및 전가가 되구요.

현실적으로 지금 프로젝트를 하는데에 개발자가 db까지 다 봐야하는 상황이면 차라리 dapper를 써서 DB는 이렇게 진행했다는 부분을 명확하게 인지하면서 가는게 낫습니다.

일단은 말씀하신대로 진행하되 닷넷 버전만 .Net 6 이상(.Net 8)으로 하시고 다른건 원하시는대로 기존 설계안대로 가시는게 좋습니다.

8개의 좋아요
15

EF core에 대해 뭔가 오해를 하고 계신 것 같습니다.

코드 우선 전략으로 생성한 DB도 DB일 뿐 EF Core 만의 DB는 아닙니다.
다른 시스템이 그 DB에 붙어서, 쿼리를 날리든 말든 그들만의 사정이지, EF, 닷넷, 또는 C# 언어와 아무런 상관이 없습니다.
.

6개의 좋아요
16

dba가 있는 환경자체도 이상적인 환경입니다.
백엔드 담당하는 개발자가 다 해야하는 경우도 심심치않게 생기죠.

그러다보면 db sql이라는 또하나의 언어쳬계와 환경자체까지 형상관리하고,
그 버전과 프로그램 버전까지 맞춰서 관리하려면 골치 아픕니다.

그렇기 때문에 node에서도 java에서도 orm을 점점 사용하는 추세로 가는거 같습니다.

그리고 제 경험상 프로젝트의 언어기반을 바꾸는 일 보다는 dbms를 바꿀일이 좀 있었습니다.
결국 db에 의존된 프로젝트에서는 유료 dbms-> 무료dbms 로 솔루션마다 다르게 설정하는 건 힘든일입니다.
그걸 가능하게 해주는게 orm 이죠.

그리고 Dapper가 아니더라도 EfCore로도 충분히 로우쿼리를 사용한 코딩이 가능합니다. (efcore7부터 지원합니다. efcore7버전은 dotnet6버전에서 사용가능합니다.)

7개의 좋아요
17

옹 dapper 얘기가 나와서 말이지 말입니닷…

저도 한 때 EF 신봉자였지만…

쓰면서 느낌점을 정리하자면
결론적으로는 이렇게 생각하게 되었슴다…

소규모 프로젝트, DB 복잡도 낮음, DBA 없음, SQL튜닝 필요 없음 → EF 강추.
대규모 프로젝트, DB 복잡도 높음, DBA 협업, SQL 튜닝이나 검토/리뷰 필요, DB 테이블이나 스키마를 직접 어플리케이션 코드에서 관리하기 어려움 → dapper 강추

일단 DBA 와 협업하는 상황에서 EF 를 사용하면… DBA 를 괴롭히게 되더군요… =ㅅ=;;(미안…)

그리고 제가 방법을 잘 몰라서 그런 거겠지만
EF 로는 실행계획 자체를 디자인 타임에 확인할 수가 없어서 많이 번거로웠슴다.
(뭐 실행계획 뿐만 아니라 실제 테스트하여 의도한 record set 을 확인하는 것도 번거롭죠.)

EF 로 raw sql 사용하는 방법이 있긴하지만… 그럴 바에 dapper 가 더 낫다는 생각이 들더라구요.
테이블 스키마를 형상관리 해야하는 부분도 부담이긴 했어요.
(POCO 생성이든, 스케폴딩이든 모델 정보가 배포 나갈 때 빠뜨리면 문제가 생기는 상황이 꽤 있었어요)

상황마다 환경마다 다르겠지만
C# 코드로 어플리케이션 단에서 DB 를 조작할 수 있다는 강점 때문에 EF 를 선호하긴 했지만

이게 또 묘하게 비즈니스 로직이 DB 와 어플리케이션의 구분 없이 사용되는 거 같은 느낌이 들어서
뭔가 좀 애매해지는 상황도 많았슴다.

지금도 회사에서는 EF 파와 dapper 파가 나뉘는 상황이라…

그래서 그냥 둘 다 쓰자! 로 결론 났…

9개의 좋아요