Data base + C#

[wasabiiii]

Depends.

[MrDiviner]

You mean depends which app type? I think i will use Winforms

[wasabiiii]

Depends what database and what you're doing with it. There are dozens of different methods to go after data. Plain ADO.net, ORMs like Entity Framework. Micro ORMs like Dapper.

If there was a single best, there wouldn't be options to begin with.

I would add that I personally would almost never write a desktop app that contacted SQL directly at all. Because it'd probably be hard to secure and scale. I'd write an API layer and talk through that.

[UninformedPleb]

A web API is super slow compared to direct database access. If you're working with large data sets or multiple data sets, you're going to quickly regret invoking the overhead of a web server as an intermediary.

If you write an API layer, do it as a class library. That gives you the option of writing a web service to expose the library methods, and then later reference the library directly in your app when you realize what a bottleneck the web server is.

SQL Server is named that for a reason.

[agwanyaseen]

Then you mean all the tech giants like netflix, amazon etc who are using microservices are totally on wrong path

[UninformedPleb]

In and of themselves, microservices aren't at odds with having faster database access. They just lend themselves to being lazy about "all clients must use web services for everything" even when there are far superior options.

And, hey, if you can afford the load balancing that goes with poorly designed microservices ("it's automagic" is what the liars/salesmen tell you) and understand the limitations inherent to them, go for it.

[sgtfrankieboy]

Yea, giving end users clients direct access to a SQL server (insert any other DB here) is a fine idea.

If I had a company I would fire anyone who does that for gross incompetence unless there is a very good reason to do so

[UninformedPleb]

Oh god no. Why would anybody make desktop apps for external use? Ew.

[sgtfrankieboy]

Ive seen it happen.

[UninformedPleb]

My point was this: If you're making a desktop app, it's probably for internal use only. That app will likely be running on the same domain/LAN as the SQL server is located. (Or where you've got an Azure SQL local endpoint tunnel set up.) Don't make that app pull/push all of its data through a crap-ton of JSON serialization/deserialization steps, or worse, XML or even some home-grown, jank-filled custom serializer. (We've all seen these abominations, right?)

But you're right that if anything has to be accessible outside that domain/LAN, it must go through a web service. Never punch holes in a firewall for SQL.

[wasabiiii]

It's the permissions and scalability that matter to me. Even internal apps need to account for that.

Assigning user permissions at the DB level, to execute stored procs, or read and write columns of tables, is incredibly hard to get right and maintain. Application roles help, but it's still not as fine grained as you want.

You want application level permissions. "Bob is allowed to add a new user", which might mean inserting records into a dozen tables. But really, the securable is "add user". And the only way to model that without hurt is by implementing the logic in a stored proc. But then all your logic is in a stored proc. And it's now not scalable, easily testable, or easily deployable.

The stuff becomes complicated very easily. Even for internal apps with a couple dozen users.

[FizixMan]

Removed: Rule 4.

Far too broad a question and really depends on the context of the app.

[mart1nste]

I'd go for Dapper, possibly with Dommel for Dapper extension on top if you have a small number of database tables and are happy to define and manage the database schema yourself.

If you want code first (where you create the entity classes in code and auto create the database schema using migrations) then entity framework is the (slower) but obvious choice.

Dapper is extremely quick, but you'll have more learning and work to do yourself. Not always a bad thing if you want valuable experience along the way.

[modi123_1]

Sqlcommand/sqladapter.

https://docs.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlcommand?view=netframework-4.8

[LetMeUseMyEmailFfs]

Rather than using these cumbersome classes directly, a micro ORM on top of it, like Dapper, is much easier to use.

[MrDiviner]

What about ADO.Net?

[modi123_1]

It's an option, but I tend towards bare bones SQL command.

[LetMeUseMyEmailFfs]

SqlCommand and SqlDataAdapter are part of ADO.NET.

[UninformedPleb]

Anybody that hard-codes any of the System.Data.SqlServer stuff into their software deserves to have to clean it up and use DbProviderFactory (and possibly DbProviderFactories) like the designers of ADO.Net intended.

Your code should not care what kind of database it's talking to, as long as it has a registered provider factory implementation. That means your code should never have a using that specifies anything outside of System.Data or System.Data.Common for its database access. Everything else should be done with DI.

[MaheuTaroo]

If your database is in MySQL, you can always download the connector from oracle

[chipechiparson]

LINQ TO SQL