.Net Questions Megathread Part 2

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .Net Questions Megathread Part 2

«‹›440 »

Gul Banana: Nov 28, 2003

Jabor posted:

Essentially, when you await something, your method returns immediately and what's left of it is tucked away as a callback. Once whatever you're awaiting completes, that callback becomes eligible for execution and at some point it will get run on the same message loop that runs your event handlers and such.

this is a reasonable way to understand it, but still a simplification. an async method compiles to a state machine, rather than closures; its different sections (separated by await operators) are invoked when reached as Tasks or anything else with a GetAwaiter method. Task is just an abstraction which does not define how to actually execute code. to initiate a task, given some function, you need a TaskScheduler, and the one used for async delegates this to a SynchronizationContext. these are what control the behaviour of async/await.

you've got a few different ones available:
- WindowsFormsSynchronizationContext - uses the win32 message loop to run each awaited Task on the ui thread.
- DispatcherSynchronizationContext - does the same thing for WPF, using the ui thread's Dipatcher rather than by dropping down to win32.
- AspNetSynchronizationContext - runs async sections on different threads, but captures the http context and locks the http application.
- AspNetSynchronizationContext in 4.5 - as above, but instead of using a global lock it schedules callbacks (each potentially in a different thread) such that there's no concurrent access to the HttpApplication.
- default SynchronizationContext - used in console apps or if a null context is supplied - runs async sections on threadpool threads. they are completely concurrent!

finally, if you're awaiting a Task that was already scheduled- perhaps by using a ThreadPoolTaskScheduler instead of a SynchronizationContextTaskScheduler - it will run wherever you put it, and only once execution returns to the code of the async method will it again be synchronized.

Gul Banana fucked around with this message at 06:28 on Jun 1, 2013

# ? Jun 1, 2013 06:23

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 18:14

wwb: Aug 17, 2004

Awesome explanation of async.

It raises one question -- does async in .NET 4.0 in ASP.NET actually have performance penalties? The lock would make me think that things could get ugly I'd think? And does it matter if your code really doesn't often touch the HttpContext?

# ? Jun 1, 2013 14:06

wwb: Aug 17, 2004

Speaking of improving forum code quality: http://sbknull.blogspot.com/2013/05/jitjotnet-alpha-release.html

# ? Jun 1, 2013 22:44

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

VS 2012 Ultimate. Where the hell did the rest of my colors go? This is the end of the list.

# ? Jun 2, 2013 01:33

Fuck them: Jan 21, 2011; and their bullshit

And now babby's first thing-that-must-be-secure-and-will-go-into-production.

I've been playing with WebAPI and there's all kinds of stuff I've seen for POSTing data to it, or big bulk file uploads, or poo poo with Azure, and serialization with json or xml or whatever. That's all fine, but not exactly what I'm looking for.

What I AM looking for is a way to securely (as much as is reasonable) send small (a meg at most, honestly, and even that is big) send files from a C# console app to the WebAPI that I'm developing, and XML/JSON serialization just makes the stubble on the back of my neck raise up. Can I REALLY send rows from two tables that contain checking account/CC numbers securely if it's done through some kind of encryption layer? How do I call that?

What I want to know is what kind of connection I can pick to put into the WebAPI's controller that would be good for having sql rows or data tables or serialized lists of objects that would be easy to set up for the WebAPI, the console app that's sending the stuff, and not be a pain to test or debug and log. The senior guys here have said line by line is better than a datatable, so I'm going to do that unless a goon here gives me a good reason not to.

I'm glad to be able to play around like this, but I'm still green as poo poo, and it's making me a little paranoid of security, honestly. I've done desktop stuff with C#/.NET and am very comfy with that, and I've done some VERY minimal WebForm stuff. This is all very new to me and I feel lost and like I'm easily going to gently caress something up, bad, if I don't cross my t's and dot my i's over and over.

# ? Jun 3, 2013 15:25

Essential: Aug 14, 2003

I cannot for the life of me figure out how to reverse this and get the original number 1 back.

This code gives me: 1 = "MDAwMQ=="

code:

Dim sID = Convert.ToBase64String(Encoding.UTF8.GetBytes(String.Format(CultureInfo.InvariantCulture, "{0:D4}", 1)))

Now I need to go the other way and get: "MDAwMQ==" = 1

Durr, nevermind. Endoding.UTF8 has a .GetString method. I'll leave this here just in case anyone else runs into this. To get the original value back you need to use the Endoding.UTF8.GetString method, which as 3 parameters; the byte array, the index and the count. Pretty easy really.

VVVV Thanks, yep you're right. I figured it out shortly after posting. VVVV

Essential fucked around with this message at 16:05 on Jun 3, 2013

# ? Jun 3, 2013 15:34

Nevett: Aug 31, 2001

Essential posted:

I know there is a Convert.FromBase64String but I cannot get it to work. Please help!

I think what you're looking for is the Encoding.UTF8.GetString method. Like so (C#, I'm afraid):

code:

int input = 1;
String base64 = Convert.ToBase64String(Encoding.UTF8.GetBytes(input.ToString()));
int output = Int32.Parse(Encoding.UTF8.GetString(Convert.FromBase64String(base64)));

// output = 1

Of course, you should make that code more defensive to bad input etc

# ? Jun 3, 2013 15:49

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

And now babby's first thing-that-must-be-secure-and-will-go-into-production.

I've been playing with WebAPI and there's all kinds of stuff I've seen for POSTing data to it, or big bulk file uploads, or poo poo with Azure, and serialization with json or xml or whatever. That's all fine, but not exactly what I'm looking for.

What I AM looking for is a way to securely (as much as is reasonable) send small (a meg at most, honestly, and even that is big) send files from a C# console app to the WebAPI that I'm developing, and XML/JSON serialization just makes the stubble on the back of my neck raise up. Can I REALLY send rows from two tables that contain checking account/CC numbers securely if it's done through some kind of encryption layer? How do I call that?

What I want to know is what kind of connection I can pick to put into the WebAPI's controller that would be good for having sql rows or data tables or serialized lists of objects that would be easy to set up for the WebAPI, the console app that's sending the stuff, and not be a pain to test or debug and log. The senior guys here have said line by line is better than a datatable, so I'm going to do that unless a goon here gives me a good reason not to.

You don't want to send files, and you don't want to serialize data tables or data rows, either. You want to have an object that represents your data that's passed from your application to your service. Passing a table/datarow with an uncertain structure means that your service is tightly coupled to the source of the data. You don't want that. What if a field name changes? What if the structure of the data changes? It means you have to change two things: The service AND the application that consumes the service. If you have a strongly-typed object that represents a contract between your application(s) and your service, you just make sure that the data fits in the contract object and you're golden. The service never needs to change unless you have to add more functionality to it.

I'm not too certain on standards for what constitutes "things that definitely won't get you sued" in regards to handling credit card info, but SSL is a good start. Google "webapi ssl".

Some considerations for sending the data all at once versus item by item:

Is there any sort of dependency on other row in the data set, or is each row discrete?
How will your program recover if the service becomes unavailable in the middle of a transaction? How will your service recover if there's a problem processing some piece of data?

Any of these things can be accounted for, but they may be easier or harder depending on how your service is consumed.

New Yorp New Yorp fucked around with this message at 16:15 on Jun 3, 2013

# ? Jun 3, 2013 16:05

Fuck them: Jan 21, 2011; and their bullshit

Ithaqua posted:

You don't want to send files, and you don't want to serialize data tables or data rows, either. You want to have an object that represents your data that's passed from your application to your service. Passing a table/datarow with an uncertain structure means that your service is tightly coupled to the source of the data. You don't want that. What if a field name changes? What if the structure of the data changes? It means you have to change two things: The service AND the application that consumes the service. If you have a strongly-typed object that represents a contract between your application(s) and your service, you just make sure that the data fits in the contract object and you're golden. The service never needs to change unless you have to add more functionality to it.

I'm not too certain on standards for what constitutes "things that definitely won't get you sued" in regards to handling credit card info, but SSL is a good start. Google "webapi ssl".

Well, that's just it. I've made a class for each table which is basically "tablenameRow" and set my properties to the relevant SqlDataTypes. I make an object for each row, basically. My little console app will be creating them from a local table and then sending them to the web service. I apologize for not being more clear.

What I'm wondering is how to set up the webservice to expect such objects to be passed to it, and how to pass them securely.

Back to google!

# ? Jun 3, 2013 16:14

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

What I'm wondering is how to set up the webservice to expect such objects to be passed to it, and how to pass them securely.

This should explain everything:
http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api

In WebAPI you have a "model" (in WCF-inspired way of thinking, a "contract"). You use that model to communicate with your service.

# ? Jun 3, 2013 16:19

uXs: May 3, 2005; Mark it zero!

2banks1swap.avi posted:

And now babby's first thing-that-must-be-secure-and-will-go-into-production.

I've been playing with WebAPI and there's all kinds of stuff I've seen for POSTing data to it, or big bulk file uploads, or poo poo with Azure, and serialization with json or xml or whatever. That's all fine, but not exactly what I'm looking for.

What I AM looking for is a way to securely (as much as is reasonable) send small (a meg at most, honestly, and even that is big) send files from a C# console app to the WebAPI that I'm developing, and XML/JSON serialization just makes the stubble on the back of my neck raise up. Can I REALLY send rows from two tables that contain checking account/CC numbers securely if it's done through some kind of encryption layer? How do I call that?

What I want to know is what kind of connection I can pick to put into the WebAPI's controller that would be good for having sql rows or data tables or serialized lists of objects that would be easy to set up for the WebAPI, the console app that's sending the stuff, and not be a pain to test or debug and log. The senior guys here have said line by line is better than a datatable, so I'm going to do that unless a goon here gives me a good reason not to.

I'm glad to be able to play around like this, but I'm still green as poo poo, and it's making me a little paranoid of security, honestly. I've done desktop stuff with C#/.NET and am very comfy with that, and I've done some VERY minimal WebForm stuff. This is all very new to me and I feel lost and like I'm easily going to gently caress something up, bad, if I don't cross my t's and dot my i's over and over.

If you're not a security expert you should stay as far away from credit card handling as you can. Let someone else do it.

# ? Jun 3, 2013 16:21

Fuck them: Jan 21, 2011; and their bullshit

uXs posted:

If you're not a security expert you should stay as far away from credit card handling as you can. Let someone else do it.

You literally told me to quit my job, just FYI. What I'm doing is keeping track of payments that were handled already for remittance/record keeping, not actually sending it to the payment processor. If that's still a danger, welp!

If it makes you feel any better one of the other contractors is going to look it over before this goes anywhere near production. Then again, he's 450 miles away, and this feels like something way out of my league.

Am I liable for this stuff? Is this a situation where I really should say "$BOSS, I have to recuse myself, sorry, get mad if you want but I'm not facing liability." ?

# ? Jun 3, 2013 16:32

zokie: Feb 13, 2006; Out of many, Sweden

If none at your job at least mentioned PCI-DSS quoting your job might not be such a bad idea.
Seriously: if your are handling credit card info your boss should tell you what and how he expects of security...

# ? Jun 3, 2013 16:37

Fuck them: Jan 21, 2011; and their bullshit

zokie posted:

If none at your job at least mentioned PCI-DSS quoting your job might not be such a bad idea.
Seriously: if your are handling credit card info your boss should tell you what and how he expects of security...

PCI-DSS? What's that? :downs:

My boss is a very hands-off, just do it kind of guy who does not know computers at all. He basically bought this business off of an associate of his who was just milking it, not getting new clients or updating anything. He's turning it around, getting new customers (great at sales!) and such, but basically all the dev work and IT work is done by contractors who are remote with the exception of myself being the jr dev in the same office, and one of the IT people being close enough to show up to work too. Everyone else is far, far away.

The Web Guy has a lot of experience but is away for the next two weeks with his main job so I'm doing the web side of it. The Senior guy working on the old product itself has 20 something years experience but is doing this as a side gig, too. I doubt he has much web experience.

Is "biz guy hires tons of contractors" a common 'thing?'

# ? Jun 3, 2013 16:42

uXs: May 3, 2005; Mark it zero!

If you're a junior dev, you definitely should not be handling credit card data.

Then again, a senior dev would know that and he would not be handling it either.

So just that knowledge alone makes you a senior security dev. You should ask for a raise! :cool:

# ? Jun 3, 2013 16:45

Uziel: Jun 28, 2004; Ask me about losing 200lbs, and becoming the Viking God of W&W.

2banks1swap.avi posted:

PCI-DSS? What's that?

Oh boy:
https://www.pcisecuritystandards.org/security_standards/documents.php?document=pci_dss_v2-0#pci_dss_v2-0
Specifically:
https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

We were handling credit card data outside of PCI compliance many years ago, and were faced with stopping handling that data or becoming PCI compliant.

# ? Jun 3, 2013 16:47

Fuck them: Jan 21, 2011; and their bullshit

uXs posted:

If you're a junior dev, you definitely should not be handling credit card data.

Then again, a senior dev would know that and he would not be handling it either.

So just that knowledge alone makes you a senior security dev. You should ask for a raise!

When I find full time, I think I might want to just run. I have no ethical problem with getting the general scaffolding of this set up, but I can't in good conscience let it get deployed until someone who knows what they're doing looks at it all.

I need to find a classy way to do this as a professional, and not just leave a dear john and run for my life.

I also might as well get paid to practice on web api poo poo, though.

Anyway gently caress contract work.

# ? Jun 3, 2013 16:49

Fuck them: Jan 21, 2011; and their bullshit

Uziel posted:

Oh boy:
https://www.pcisecuritystandards.org/security_standards/documents.php?document=pci_dss_v2-0#pci_dss_v2-0

We were handling credit card data outside of PCI compliance many years ago, and were faced with stopping handling that data or becoming PCI compliant.

So just how far does liability go? To the business? To anyone working on that part of it?

Like, do I have a good reason to say "Hey, sorry, I'm done, here's why" or can I keep plugging away at this and then say "don't deploy this until XYZ happens" and stay busy?

# ? Jun 3, 2013 16:50

uXs: May 3, 2005; Mark it zero!

Do you actually need those credit card numbers? No other way of identifying customers?

And where do you get them anyway? Aren't payments handled by a payment processor of some kind?

# ? Jun 3, 2013 16:52

Essential: Aug 14, 2003

2banks1swap.avi posted:

You literally told me to quit my job, just FYI. What I'm doing is keeping track of payments that were handled already for remittance/record keeping, not actually sending it to the payment processor. If that's still a danger, welp!

When you dig into PCI-DSS you realize how tight they are, for instance you can have NO unencrypted at rest credit card numbers. Meaning, if you are doing record keeping you need to make sure the credit card numbers are encrypted. This includes having credit card information written down, you cannot do that either. Nor can you have credit card information recorded on voice. There are a few time-limited exceptions, such as if you must write down a credit card number to process a sale, you have something like 24 hours to process the sale, then the paper must be shredded.

Just keep in mind at rest encryption, that is an absolute must.

# ? Jun 3, 2013 16:54

Fuck them: Jan 21, 2011; and their bullshit

uXs posted:

Do you actually need those credit card numbers? No other way of identifying customers?

And where do you get them anyway? Aren't payments handled by a payment processor of some kind?

We kind of are that processor. Or at least we're a middleman giving it to them. Not sure of the proper terminology.

We're getting the information from their own accounting software; we read it into our own software to just automate the billing and tracking and record keeping. What I'm doing is taking copies of that data, sending it to a DB that's on our website, and setting it up so we can offer them a web portal that lets them look at their remittance data, as well as their payees.

Yeah I feel exceptionally in over my head right now.

# ? Jun 3, 2013 16:54

Dietrich: Sep 11, 2001

2banks1swap.avi posted:

Well, that's just it. I've made a class for each table which is basically "tablenameRow" and set my properties to the relevant SqlDataTypes. I make an object for each row, basically. My little console app will be creating them from a local table and then sending them to the web service. I apologize for not being more clear.

What I'm wondering is how to set up the webservice to expect such objects to be passed to it, and how to pass them securely.

Back to google!

Oh god.

Tables change. Datatypes change and columns get added and schemas alter as things get added. You do not want to code your business logic around the table's structure directly, or you'll be changing your business logic when the table changes. Your business logic should only change when the requirements change. Look, you need to spend some time learning about ORMs. Nhibernate, Entity framework, even a micro ORM like LinqToSql is going to make your life much better. You should have a separate .net entity that represents the tables and updates as the table changes, and your business entity should map to and from the database entity to persist and hydrate data.

# ? Jun 3, 2013 16:55

Fuck them: Jan 21, 2011; and their bullshit

Essential posted:

When you dig into PCI-DSS you realize how tight they are, for instance you can have NO unencrypted at rest credit card numbers. Meaning, if you are doing record keeping you need to make sure the credit card numbers are encrypted. This includes having credit card information written down, you cannot do that either. Nor can you have credit card information recorded on voice. There are a few time-limited exceptions, such as if you must write down a credit card number to process a sale, you have something like 24 hours to process the sale, then the paper must be shredded.

Just keep in mind at rest encryption, that is an absolute must.

What does at-rest mean? We're getting it plain text from their billing software locally, then the little console app will send it to the web service, then send that to the db on our website. Do you mean that our customers need to store their stuff encrypted on disk?

Or do you mean the actual strings in memory have to be encrypted?

# ? Jun 3, 2013 16:56

Fuck them: Jan 21, 2011; and their bullshit

Dietrich posted:

Oh god.

Tables change. Datatypes change and columns get added and schemas alter as things get added. You do not want to code your business logic around the table's structure directly, or you'll be changing your business logic when the table changes. Your business logic should only change when the requirements change. Look, you need to spend some time learning about ORMs. Nhibernate, Entity framework, even a micro ORM like LinqToSql is going to make your life much better. You should have a separate .net entity that represents the tables and updates as the table changes, and your business entity should map to and from the database entity to persist and hydrate data.

The senior guy is very much into "KISS" and shoots those ideas down a lot. They don't even like when I suggest more thorough testing or validation of data.

Did I mention I'm junior as poo poo?

Is learning to not be a lovely programmer always something that starts with realizing you're a complete idiot about more than trivialities and school didn't prepare you for poo poo? I feel that the only good thing I'm doing right now is realizing I need help and that I can't get it at this workplace.

We don't even have source control.

# ? Jun 3, 2013 16:59

Essential: Aug 14, 2003

2banks1swap.avi posted:

What does at-rest mean? We're getting it plain text from their billing software locally, then the little console app will send it to the web service, then send that to the db on our website. Do you mean that our customers need to store their stuff encrypted on disk?

Or do you mean the actual strings in memory have to be encrypted?

At rest meaning on disk, in the database. Your website db, the information must be encrypted there. Ideally it's always encrypted except when being sent to the processor over their secure (ssl) channel.

I should also mention that when your console app send's it to your website it must be sent over ssl. Your console app should first encrypt the credit card numbers, then send over ssl and store it encrypted in your db.

Essential fucked around with this message at 17:02 on Jun 3, 2013

# ? Jun 3, 2013 16:59

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

We don't even have source control.

This is totally unacceptable, especially for a team where most of the members are working remotely.

At the very least install TFS express on your workstation so you can have some sort of source control for yourself.

# ? Jun 3, 2013 17:01

Fuck them: Jan 21, 2011; and their bullshit

Ithaqua posted:

This is totally unacceptable, especially for a team where most of the members are working remotely.

At the very least install TFS express on your workstation so you can have some sort of source control for yourself.

I feel like I'm getting a crash course in how NOT to develop. Holy poo poo.

Also to everyone w/r/t PCI stuff: we only get the last four digits of data. Clients can store however they want but what my stuff will be seeing is only masked data. Phew.

The fact that I had to go bug my boss instead of having this info given to me is also making me kick myself for taking this job.

# ? Jun 3, 2013 17:03

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

Don't get discouraged, the first step to improving as a programmer is realizing that you don't know everything and will never know everything. Embrace your ignorance and work to improve. Everyone in this thread has committed numerous coding atrocities in their career, and we all will commit more coding atrocities in the future.

# ? Jun 3, 2013 17:08

Dietrich: Sep 11, 2001

Yeah even if your team doesn't use source control, it doesn't mean you can't use source control. Git is a good one, and creates next-to-no files to have to ignore when syncing your local directory with the shared one- just don't include the .git folder.

# ? Jun 3, 2013 17:11

Fuck them: Jan 21, 2011; and their bullshit

The way things were was SrGuy is doing his poo poo with the legacy code, and WebGuy is doing his poo poo with the website, and all things were essentially separate.

Looks like getting people on source control and getting some better testing/design implemented might be good experience and resume padding, at the very least.

Blaaaaaaah I can't wait for a better ran shop.

# ? Jun 3, 2013 17:35

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

The way things were was SrGuy is doing his poo poo with the legacy code, and WebGuy is doing his poo poo with the website, and all things were essentially separate.

Looks like getting people on source control and getting some better testing/design implemented might be good experience and resume padding, at the very least.

Blaaaaaaah I can't wait for a better ran shop.

What if "web guy" is incapacitated in some way and you need to pick up his work? What if he needs to see when and why a change was made two years ago? What if you need to see that? What if there's a bug in production and want to patch it, but you've already started working on new code and things aren't in a release-ready state? These are all common problems, and source control solves them completely.

TFS Express is free for up to 5 developers and will let you set up source control and automated builds with very little effort. It's dead simple to install, and it integrates right into VS2010/2012. You can even use Git for the source control portion, although I generally don't see a need for that unless you have a specific need for Git. [Insert standard disclaimer that I work in the ALM consulting field and promote TFS because (in addition to TFS being a really good product, for real) people using TFS pays my bills]

New Yorp New Yorp fucked around with this message at 17:54 on Jun 3, 2013

# ? Jun 3, 2013 17:51

Fuck them: Jan 21, 2011; and their bullshit

Conf call revealed they had a SVN all along when I brought up TFS. Thanks for the suggestion, though! Too bad I can't get set up for it until 5 pm tonight when the sr guy is done with his main job.

Right now I'm figuring out the best way to do what dietrich suggested, and separate the code for "move the data from that desktop to the web service" from "this is what the data is and where it goes."

Would having the class define "this goes here and that goes there" while having the client just send the object to the web service, and the web service call a method defined for the object's class to do the "poo poo goes here and there" for the sql insert/update work, or am I not looking at it the right way?

Not being able to even get into the projects for the existing stuff is frustrating. The fact that I am VERY new to web stuff is also frustrating. Sink or swim is not very fun!

# ? Jun 3, 2013 19:32

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

Right now I'm figuring out the best way to do what dietrich suggested, and separate the code for "move the data from that desktop to the web service" from "this is what the data is and where it goes."

Would having the class define "this goes here and that goes there" while having the client just send the object to the web service, and the web service call a method defined for the object's class to do the "poo poo goes here and there" for the sql insert/update work, or am I not looking at it the right way?

There are three pieces here:
1) A model of your data. This is a class (or a bunch of classes) that represent your data in a logical way.
2) An application responsible for turning something into a model of your data. This is your console application.
3) An application responsible for processing the model of your data. This is your service.

In this case, the object model specified in #1 is shared between #2 and #3. Read the WebAPI tutorial I posted a link to earlier, you want to do exactly that. Let's say the model we're talking about in #1 is called Widget. Your first app creates a bunch of Widget objects, and then passes them off to #3, which has a method signature like public void Process(Widget foo).

In the .NET world, we prefer "thin" models. The model class is pretty much nothing but properties, with as little internal logic as possible. Your model doesn't do things, other things manipulate your model.

# ? Jun 3, 2013 19:48

Fuck them: Jan 21, 2011; and their bullshit

That's what I was doing :confused:

I either need to learn better lingo or work on my grammar. Or both.

I didn't understand Dietrich, or, I explained it badly.

# ? Jun 3, 2013 20:41

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

That's what I was doing

I either need to learn better lingo or work on my grammar. Or both.

I didn't understand Dietrich, or, I explained it badly.

Slap some sample code on pastebin.

# ? Jun 3, 2013 20:51

Fuck them: Jan 21, 2011; and their bullshit

Just got home and I have to take a call in a few, so I just whipped up something cheeky to see if I get the point or if I'm missing it.

http://pastebin.com/kMCNff5B

When I'm back at work I could get some code, but you asked me after I left for the day.

Hey at least an interview is tomorrow where they have actual senior people and they're actually in the same state (and room!) as me, hooray.

# ? Jun 3, 2013 21:41

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

2banks1swap.avi posted:

Just got home and I have to take a call in a few, so I just whipped up something cheeky to see if I get the point or if I'm missing it.

http://pastebin.com/kMCNff5B

When I'm back at work I could get some code, but you asked me after I left for the day.

Hey at least an interview is tomorrow where they have actual senior people and they're actually in the same state (and room!) as me, hooray.

See, you're doing the thing I said not to do. Your model class should be acted upon, not take actions. The only purpose your model has is to structure your data appropriately.

Let's take your specific case. You'll ultimately want to persist your model to a database. The way you're thinking of doing it, the model can be persisted to the database at any point. Your model will have knowledge of everything it needs to do to persist itself to a database, which totally defeats the purpose of having a service.

If you'll need to persist your widgets to a database in multiple places (and chances are you will!), that's where the repository pattern comes into play. You have a class that has a single responsibility: Understanding how to persist a Foo object to a database. Anything that needs to work with Foos can use a FooRepository to do so.

Also, a few style notes:

Your method/variable names don't adhere to Microsoft's naming conventions. I'm a stickler for pointing that out
Always explicitly declare the access modifier of fields/properties/etc
Never use public fields. Use properties (public string Foo {get; set; }) instead. There's a really good reason for that, but I'm not going to go into detail.
Actually, I'm pretty sure the default access modifier on fields when it's not explicitly stated is private, so I think you did the right thing unintentionally. But it was clear that your intent was to use public fields, which is a no-no.

New Yorp New Yorp fucked around with this message at 22:06 on Jun 3, 2013

# ? Jun 3, 2013 22:00

Fuck them: Jan 21, 2011; and their bullshit

Ithaqua posted:

See, you're doing the thing I said not to do. Your model class should be acted upon, not take actions. The only purpose your model has is to structure your data appropriately.

Let's take your specific case. You'll ultimately want to persist your model to a database. The way you're thinking of doing it, the model can be persisted to the database at any point. Your model will have knowledge of everything it needs to do to persist itself to a database, which totally defeats the purpose of having a service.

Also, a few style notes:

Your method/variable names don't adhere to Microsoft's naming conventions. I'm a stickler for pointing that out

Always explicitly declare the access modifier of fields/properties/etc

Never use public fields. Fields should never be public. Use properties (public string Foo {get; set; }) instead. There's a really good reason for that, but I'm not going to go into detail.

Okay, the model should just be properties/getters/setters, period - are constructors acceptable or should there be a factory method?

Dietrich's advice to make there be less places I'd have to make changes to behavior if the table changed made me think I should tie that in with the objects themselves. If the Controller handles "looks at model and then does the SQL insert/update" and the desktop app does "turns the local data from the DB into the model" then I'd have two places to change it. There's not a great deal of logic there to worry about, so I'm not concerned. Hell, everyone at work insists it won't change at all and if it does it would be once in a blue moon at most, so I'm not worried about that so much as learning how to do it how good programmers expect things to be written.

I feel like I either completely misread something or the fact that my work does not use orms and tends to lean on stored procs is why I'm being guided into this style. Or there's something else I'm not getting, or I wasn't ever supposed to centralize "making objects of the model" and "doing a thing with that model object" in the first place.

# ? Jun 3, 2013 22:22

gariig: Dec 31, 2004; Beaten into submission by my fiance; Pillbug

I need help to find an elegant solution to a problem. I sometimes need to write a lot of code where I'll have one input that I need to parse but have several rules. If one of those rules matches the input I can stop parsing the input. I normally end up with a bunch functions that return a boolean and do something like

C# code:

bool success=false;
success=RuleOne(input);
if(success)
	return;

success=RuleTwo(input);
if(success)
	return;

Is there a better way to structure code like this? It just annoys me

EDIT: VVVV Holy crap. I didn't even think about using short circuiting in a return statement to do the logic. That'll be perfect.

gariig fucked around with this message at 23:36 on Jun 3, 2013

# ? Jun 3, 2013 23:13

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 18:14

JawnV6: Jul 4, 2004; So hot ...

C# code:

return RuleOne(input) || RuleTwo(input);

Look up "short circuit evaluation" if that doesn't make sense. Check RuleOne, if it's true bail on evaluating the rest, if false check RuleTwo, etc.

# ? Jun 3, 2013 23:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .Net Questions Megathread Part 2

«‹›440 »