Starting a dotnet job next week. What am I in for...

Starting a dotnet job next week. What am I in for? Hear I'm going to be writing a lot of sql and taking json docs between databases and different parts of my company.

Attached: 1527208216861.jpg (800x450, 12K)

Other urls found in this thread:

dotnetcurry.com/
twitter.com/NSFWRedditImage

You're going to work with Windows

That Im aware of. apparently they use all windows applications there. Everything is windows linked. which isnt bad for me. Ive been using windows most of my life.

Like almost everybody else.

I'm actually going through a c# and .net book right now, any advice op?

>writing a lot of sql
>when using C#, with entity framework and LINQ
For what purpose?

Don't fall into the trap of learning all the dotnet technologies. Most of the time, companies are using only a specific tech stack of dotnet. Just make sure you know how to program and focus on one aspect of dotnet at a time. Most dotnet jobs specialize in one area (wcf, whether they use linq or EF for database shit, etc).

I don't know, but it's not my problem. I'm getting paid good so I'm just following what they want me to use.

What is .NET about?

I know the basics of C#. I haven't had the time to learn more of it because I've been working on other projects, but to me .NET just seems like a collection of libraries. Is that it?

Grab a book or check this site out or use M$'s tutorial docs. There's many resources to figure it out.

>doesn't understand why people continue to ask easily googled questions on Jow Forums

dotnetcurry.com/

Maintaining incredibly poorly designed systems.

I don't know what it is about .NET shops that attracts bad devs. I've never seen a good one.

Entity sucks with big queries. That's why Dapper exists.

I'm a C++ dev who took up the job cause they offered me a lot of money and benefits. I've used C# and dotnet back in the day, so it's not a bad thing to take up. But I've heard already that there are different builds all across the dev team, so I'm already anxious.

Is .NET literally just a less outdated Java? The jobs for the two languages are similar.

Yes. dotnet is becoming the new norm for Java-like jobs, simply because windows is a lot more competitive with their suite of software. Some companies wont transition cause they're already built heavily on Java.

Could you expand a little bit on how you mean by how to program? I'm still a student right now and going over c++ in my spare time too
How much are you getting paid? How much experience do you have?

As long as you know the fundamentals of programming, like variables, OOP, logic flow, etc, you know how to program. C# is used mostly with dotnet, so learn as much as you can about the language. C# and dotnet are NOT the same thing, so knowing one doesnt mean you know the other. As for payment, I get paid 90K with benefits, but that's only cause I have over six years in the industry.

Attached: dotpajeet2.png (624x329, 402K)

I should have taken the C++ job

Attached: 1502963955335.jpg (251x234, 7K)

Dear friend, learn to speak pajeet and write an endless shitstorm of OOP crap that does literally nothing and impossible to debug.

Indians

Macfag here.
Is it feasible to get into .NET without using Windows?

Yes. The reason .net was created was to have a cross platform language for interacting with Windows-like apps. Basically, M$ knew that cross platform was where the money was and made it so any language can tap into it.

what's the point of C# corner? i litearlyl never found useful information there and it's always dozens of Indian comments where it says thank you dear friend for this article, do they get points for that or what?

Generic enterprise job which is surprisingly comfy in dotnet

how is it comfy

.NET Core
look it up.

You have the options of framework (Windows only + BCL), .NET standard (BCL), .NET Core (x-platform + BCL).


you're in for one of the following:
[web] - lots of javascript or typescript (if your company is up to date), CSS/SASS, and C# for your apis/services/repositories.

[winforms/wpf] - wpf will be ass, it's very niche due to the UX part of it. Winforms will be easy, look into multi-threaded processing. Some of the places I've worked only used BackgroundWorkers (built into .net), some have started using async/await, some still create new threads and use delegates to talk back and forth.

a C# job, especially an "application" one and not a "web" one, is going to vary heavily from workplace to workplace.

As per people going "why sql i got muh endidees and muh zelda", code monkeys can churn out EF easy. EF is very much a code first, performance later design. stored procedures will always reign supreme in terms of speed and ability to release updated logic to customers without having them agree to an update. It also allows the SQL weak people to have someone write their SP and you just have to do the tedious task of calling it and writing bullshit boilerplate code that no one else wants to.

-- YES this is a thing. Especially the "update without customer approval". Many companies sell patches or give users the ability to "opt-in" via feature driven development. That being said.. if the user doesnt want that feature, but wants one specific thing for it, it's not uncommon to give them their own version of a stored procedure. Especially if you have a list of SP calls that you dynamically call that can be rewritten easily on the fly.

TL;DR

prepare to do whatever your boss / client wants. and you'll more than likely do it in ways that seem stupid on the surface, but if you get into the nitty gritty they make sense.

good luck have batman op

I always hear about stored procedures. What ARE they? Are they just queries people write and then are just called repeatedly like a function?

ehh.. not exactly.

Functions in SQL normally return single values, they can return a table but I haven't seen this as often.

A stored procedure is something you can call that normally has some bundled logic. Many return 1+ table(s), some declare parameters as OUTPUT, and some just run and raise error if something goes wrong (im not a fan of the latter).


Entities is commonly used for CRUD operations, but if the logic gets weird, it's not uncommon for stored procedures to be introduced to reduce DB calls, be more efficient, and finish faster.

If they said it's going to be SQL heavy, lookup some T-SQL tutorials. Useful items would be: selects, updates, subqueries, transactions, CTEs, triggers (yeah... people still abuse these), stored procedures, indexes, normalized table structure, Composite Keys, Surrogate Keys, indexes. (roughly in that order of importance. the composite keys and surrogate keys are important to know/understand, but they're relatively simple. bear in mind if a company uses composite keys, they likely aren't doing normalized table structures).

I forgot to mention insert statements. Permissions (e.g. grant update on x to y) can also be useful, knowing how to output inserted/updated items into a seperate table is useful.

e.g.,
update x
set [values]
output inserted.value1, inserted.value2
into #tmpTable
from table x
where [condition for table]

if yuor'e brand new, dont worry too much about it. it's more about getting along with your team and showing them you're willing to learn.