.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »

smarion2: Apr 22, 2010

Munkeymon posted:

Linq is really good and I miss the hell out of it when I use other languages.

Just curious what do you like most about it? I did find it pretty handy doing some data manipulation on datatables but that's all I ever used it for.

# ? Aug 25, 2016 20:57

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 08:14

EssOEss: Oct 23, 2006; 128-bit approved

I use LINQ every day! Well, I mean I use the LINQ extension methods, not the weird SQL-ish syntax.

For example, today I wrote the following code to get all the categories of an entity that match a whitelist:

code:

var allowedCategories = new[] { "A", "B", "C", "D" };

var categories = entity["categoryBlobs"]
    .Select(blob => blob.CategoryName?.Value<string>())
    .Intersect(allowedCategories)
    .Distinct()
    .ToArray();

Sure, I could have done it another way - I suppose I could foreach through the categoryBlobs and do each step in a loop and then do some crappy manual implementation of Distinct(), I guess. But that just feels wrong after using LINQ for a while. This is simple, straightforward and relatively bulletproof.

Async/await is also awesome, especially if you deal with things that need to be responsive (UI code) and especially on weak devices (e.g. Windows Phone). By going from a multithreaded model to an async model, I totally eliminated a whole bunch of performance issues and jitters in an app I had made. It takes a bit of time to understand but once you get it, it just makes so much sense!

EssOEss fucked around with this message at 21:17 on Aug 25, 2016

# ? Aug 25, 2016 21:15

smarion2: Apr 22, 2010

Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug.

# ? Aug 25, 2016 21:28

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

smarion2 posted:

Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug.

First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way.

# ? Aug 25, 2016 21:37

bigmandan: Sep 11, 2001; lol internet; College Slice

Ithaqua posted:

First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way.

I'm fairly new to C# and I have been trying to wrap my head around this over the past week. I found an article that helped me understand it better. The visuals really helped.

# ? Aug 25, 2016 21:44

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

smarion2 posted:

Just curious what do you like most about it? I did find it pretty handy doing some data manipulation on datatables but that's all I ever used it for.

Making data manipulation code a lot easier to write is exactly why I like it. Contrary to some old posts of mine ITT, I've even gotten into the SQL-like syntax because it can be even easier and more concise than chaining extension calls, especially when things get really hairy.

# ? Aug 25, 2016 21:49

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

smarion2 posted:

Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug.

You can do some pretty baller stuff. Today I was running this

code:

var invalidSegmentCount =
mediaPlaylist.MediaSegments
.Select(async s => await VerifyRemoteFileExists(localVariantUrl, s.Uri))
.Count(v => !v.Result.Valid);

I have a bunch of URIs that I want to do HTTP HEAD checks on. This is running them one at a time. Do you know how I made this "multi-threader"?

code:

var invalidSegmentCount =
mediaPlaylist.MediaSegments.Select(async s => await VerifyRemoteFileExists(localVariantUrl, s.Uri))
.AsParallel()
.Count(v => !v.Result.Valid);

That's the power of LINQ. Since I didn't tell the compiler what I wanted with foreach loops but said: I have a collection and I want to map that collection to a function to get a collection of results then Count how many are invalid. I could just stick AsParallel in and it did everything multithreaded without any code from me.

# ? Aug 25, 2016 21:52

raminasi: Jan 25, 2005; a last drink with no ice

smarion2 posted:

Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug.

Well, LINQ is actually usually a hair slower. But it's just so much more clear and readable. Use LINQ.

# ? Aug 25, 2016 22:12

amotea: Mar 23, 2008; Grimey Drawer

Ithaqua posted:

Why aren't you disposing the Image objects? That should clean up the unmanaged memory. calling GC.Collect() is almost always a bad thing.

Yeah I know, you're missing the point, the Image is just a view element in XAML on which you can change the Source (and it isn't disposable anyway). I dug up this minimal reproduction sample:

code:

            using (var outStream = new MemoryStream()) {
                BitmapEncoder enc = new BmpBitmapEncoder();
                var frame = BitmapFrame.Create(bitmapImage);
                enc.Frames.Add(frame);
                enc.Save(outStream);
            }

bitmapImage is a BitmapImage. Run this 25 times or so for e.g. a 4000*4000 BitmapImage and it'll run out of memory in a 32-bit process. There's nothing to dispose here (except the MemoryStream), the internal Bitmap stuff doesn't dispose of its native memory I guess because it doesn't know when to (and the GC doesn't know theyre taking up memory).

# ? Aug 25, 2016 22:25

RICHUNCLEPENNYBAGS: Dec 21, 2010

Munkeymon posted:

Linq is really good and I miss the hell out of it when I use other languages.

I feel like everybody these days is getting something kind of similar (although I guess most of them aren't lazily evaluated).

# ? Aug 25, 2016 22:49

RICHUNCLEPENNYBAGS: Dec 21, 2010

Bognar posted:

If you haven't seen it yet, here's the list of potential C# 7 features.

https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/

Looks like a great list.

# ? Aug 25, 2016 23:01

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Munkeymon posted:

Linq is really good and I miss the hell out of it when I use other languages.

At happy hour with a colleague recently we discussed how nice it would be to have a Java Extension for Linq Querying.

# ? Aug 25, 2016 23:10

smarion2: Apr 22, 2010

Ithaqua posted:

First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way.

Ahhh thanks for the distinction!

gariig posted:

You can do some pretty baller stuff. Today I was running this
code:
var invalidSegmentCount =
mediaPlaylist.MediaSegments
.Select(async s => await VerifyRemoteFileExists(localVariantUrl, s.Uri))
.Count(v => !v.Result.Valid);
I have a bunch of URIs that I want to do HTTP HEAD checks on. This is running them one at a time. Do you know how I made this "multi-threader"?
code:
var invalidSegmentCount =
mediaPlaylist.MediaSegments.Select(async s => await VerifyRemoteFileExists(localVariantUrl, s.Uri))
.AsParallel()
.Count(v => !v.Result.Valid);
That's the power of LINQ. Since I didn't tell the compiler what I wanted with foreach loops but said: I have a collection and I want to map that collection to a function to get a collection of results then Count how many are invalid. I could just stick AsParallel in and it did everything multithreaded without any code from me.

That is freaking amazing I want to get really good at Linq now...

raminasi posted:

Well, LINQ is actually usually a hair slower. But it's just so much more clear and readable. Use LINQ.

It's probably still faster than MY code.... HA!

# ? Aug 26, 2016 00:03

mystes: May 31, 2006

Inverness posted:

I'd like to know more about your DataGridView issue. Were you using row virtualization?

I was trying to; it's on by default, right? I may very well have been doing something wrong, causing it to load more rows than necessary, however. The problem was that scrolling seemed pretty slow, but I didn't try to debug it too much, because it seemed like the WPF datagridview control would be really inappropriate for my next goal (changing the color of individual cells based on the result of calculations performed in another thread). Frankly, the whole row virtualization thing was much clearer with Windows Forms since you essentially just have to implement one function to provide the data when required, rather than setting the itemsource and praying that your object will work with row virtualization (different tutorials seem to do different cryptic things which may or may not be required to actually get row virtualization to function in WPF).

# ? Aug 26, 2016 02:22

Inverness: Feb 4, 2009; Fully configurable personal assistant.

mystes posted:

I was trying to; it's on by default, right?

Ah, yes it seems it is. I was expecting something more like WinForms.

quote:

I may very well have been doing something wrong, causing it to load more rows than necessary, however. The problem was that scrolling seemed pretty slow, but I didn't try to debug it too much, because it seemed like the WPF datagridview control would be really inappropriate for my next goal (changing the color of individual cells based on the result of calculations performed in another thread). Frankly, the whole row virtualization thing was much clearer with Windows Forms since you essentially just have to implement one function to provide the data when required, rather than setting the itemsource and praying that your object will work with row virtualization (different tutorials seem to do different cryptic things which may or may not be required to actually get row virtualization to function in WPF).

Changing colors from another thread is simple: just use the object's dispatcher instead of trying to access it directly.

In any case, I don't think the control necessarily has an issue with large amounts of data. I assume that was planned from the beginning given the nature of the control.

Also, make sure you're not putting the DataGridView inside a scroll viewer as that will cause it to expand infinitely.

In any case, how many rows and columns were you doing here? I'm curious and want to investigate the performance issue myself.

# ? Aug 26, 2016 03:07

Mister Duck: Oct 10, 2006; Fuck the goose

amotea posted:

Yeah I know, you're missing the point, the Image is just a view element in XAML on which you can change the Source (and it isn't disposable anyway). I dug up this minimal reproduction sample:
code:
            using (var outStream = new MemoryStream()) {
                BitmapEncoder enc = new BmpBitmapEncoder();
                var frame = BitmapFrame.Create(bitmapImage);
                enc.Frames.Add(frame);
                enc.Save(outStream);
            }
bitmapImage is a BitmapImage. Run this 25 times or so for e.g. a 4000*4000 BitmapImage and it'll run out of memory in a 32-bit process. There's nothing to dispose here (except the MemoryStream), the internal Bitmap stuff doesn't dispose of its native memory I guess because it doesn't know when to (and the GC doesn't know theyre taking up memory).

Have you run this on 4.6.2? The memory management behind bitmaps was changed to call GC.Add/RemoveMemoryPressure so it might have helped your issue slightly. But yes, you still could conceivably outpace the GC doing that.

# ? Aug 26, 2016 03:31

AWWNAW: Dec 30, 2008

LINQ is also a good gateway drug into functional programming.

# ? Aug 26, 2016 05:50

Mister Duck: Oct 10, 2006; Fuck the goose

amotea posted:

We've had OutOfMemoryExceptions popping up out of SyncFlush() when displaying a BitmapImage in an Image control. The problem IIRC was that the GC didn't kick in in time when swapping images because it didn't track the unmanaged memory.

So the user would e.g. swap the image in the Image control a few times, thereby raising the unmanaged memory usage with a few hundred MB (high res images), but the GC didn't release the old native handles because managed memory was still low. We "fixed" this by just calling the GC manually like so in tactical spots:
code:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Artificially raising managed memory consumption using GC.AddMemoryPressure didn't really seem to help at the time.

I somehow didn't fully read the original post here, sorry. The "out of memory" that comes from SyncFlush is not really out of memory. Think of it this way, if you ever get an out of memory error it should be pretty much a fail fast. Once you fail an allocation, you're pretty much screwed. In the case of SyncFlush, the error you are seeing happened some time ago and there were likely many many allocations between the time the error occurred and the time you saw the SyncFlush. Just to even fire a SyncFlush requires allocations, so very likely this isn't a memory issue.

What we see a lot in these cases is that what you're really running out of is GDI handles due to the fast allocation of bitmaps and the fact that the finalizers haven't yet released the native GDI resources. Forcing a GC would run the finalizers (as you know) and likely the handles being freed are what fixed your problem.

If you actually ran out of per process memory that would be interesting, did you check it with task manager/process explorer?

# ? Aug 26, 2016 06:16

amotea: Mar 23, 2008; Grimey Drawer

Mister Duck posted:

I somehow didn't fully read the original post here, sorry. The "out of memory" that comes from SyncFlush is not really out of memory. Think of it this way, if you ever get an out of memory error it should be pretty much a fail fast. Once you fail an allocation, you're pretty much screwed. In the case of SyncFlush, the error you are seeing happened some time ago and there were likely many many allocations between the time the error occurred and the time you saw the SyncFlush. Just to even fire a SyncFlush requires allocations, so very likely this isn't a memory issue.

What we see a lot in these cases is that what you're really running out of is GDI handles due to the fast allocation of bitmaps and the fact that the finalizers haven't yet released the native GDI resources. Forcing a GC would run the finalizers (as you know) and likely the handles being freed are what fixed your problem.

If you actually ran out of per process memory that would be interesting, did you check it with task manager/process explorer?

I remember the used memory in task manager stalling somewhere around 1200MB, the used memory reported by the GC was usually about ~70MB IIRC. If I can find some time next week I'll try to see what happens when I run the repro sample now on 4.6.2.

# ? Aug 26, 2016 13:09

Gul Banana: Nov 28, 2003

Charlie Mopps posted:

MIcrosoft should promote F# instead of trying to turn C# into a worse F#.

that would be a bad plan, because F# is an inadequate C#

# ? Aug 26, 2016 14:16

ljw1004: Jan 18, 2005; rum

Charlie Mopps posted:

MIcrosoft should promote F# instead of trying to turn C# into a worse F#.

I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science?

A couple of years ago I had Dave Wecker come talk about his F# project "LIQUi|>", a quantum computing simulator. That was the most mind-blowing my mind has been blown in decades. https://www.microsoft.com/en-us/research/project/language-integrated-quantum-operations-liqui/

# ? Aug 26, 2016 15:44

Mr Shiny Pants: Nov 12, 2012

Make F# the other language they promote heavily. Make .Net core work with it, make WPF bindings easy, make it as ubiquitous as C# is right now.

# ? Aug 26, 2016 16:33

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

ljw1004 posted:

I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science?

Oh, I think it's simpler than that: F# needs full out-of-the-box support in Visual Studio.

Right now, Visual F# itself is an optional checkbox in the installation, so people who hear about F# have to first go back and install it. Then, Visual F#'s tooling is so insultingly barebones that the F# Power Tools - a Gallery extension most users won't know about - are mandatory if you want such utter luxuries as "Rename refactoring", "Find all references" or "Folder organization". Then, you still won't have any decent project templates; you need to clone a GitHub repo like Project Scaffold, or get them from the various open-source project like Websharper, FsXaml, Yeoman Generator (a npm tool!) and so on.

Compare that to VB, the other "lesser" .NET language (no disrespect meant, Lucian; I do VB for a living and honestly like it better than C# overall, but I call it how it is). Most Visual Studio users don't write VB either, but nevertheless they already get it "for free" - in the new Preview 4 installed, if I'm reading the screenshot correctly, it's bundled under ".NET Desktop development", on equal footing with C#. They can just find the many templates under New Project and have everything set up for working with VB, no extra steps required.

Like it or not, the vast majority of the .NET audience is hugely influenced by whether or not Microsoft is putting a new technology front and centre in its products, or whether it's treated as a side project that will go the way of IronPython. If you want more people to try out F# - and I'm firmly convinced it's such a charming language that that's all it needs to succeed - this is where I'd start:

- Integrate all the features of F# Power Tools into the basic Visual F# package, or include it as part of the same installation
- Make the Visual F# Package automatically included in all of the following Visual Studio components: Web Development, .NET Desktop Development, Mobile Development with F#. Also UWP Development, once the work on .NET Native support is finished.
- (this is important) Provide some good templates for F# development! They're already available online, they just need to be packaged with Visual Studio so people can discover them and get intrigued. Off the top of my head, these would all be great:

- A WPF desktop template showing off the FsXaml type provider
- A Xamarin cross-platform mobile F# template
- A pure F# ASP.NET MVC 5 web template
- A Data Access Layer template showing off one of the various SQL type providers
- A MBrace template showing off the Azure integration through computation expressions (this one would double as an Azure promotion!)
- A Suave-based webservice template
- A frontend web template using one of the various F#-to-JS open source compilers (Fable, Websharper, or FunScript)

# ? Aug 26, 2016 16:35

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

Cuntpunch posted:

At happy hour with a colleague recently we discussed how nice it would be to have a Java Extension for Linq Querying.

You mean Java 8 streams are or you referring to something like the weird sql syntax? Or IQueryable?

# ? Aug 26, 2016 19:17

smarion2: Apr 22, 2010

ljw1004 posted:

I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science?

A couple of years ago I had Dave Wecker come talk about his F# project "LIQUi|>", a quantum computing simulator. That was the most mind-blowing my mind has been blown in decades. https://www.microsoft.com/en-us/research/project/language-integrated-quantum-operations-liqui/

This link isn't working for me but it does sound amazing and I'd like to read it!

# ? Aug 26, 2016 20:19

Mister Duck: Oct 10, 2006; Fuck the goose

amotea posted:

I remember the used memory in task manager stalling somewhere around 1200MB, the used memory reported by the GC was usually about ~70MB IIRC. If I can find some time next week I'll try to see what happens when I run the repro sample now on 4.6.2.

Interesting. If the bitmaps were hanging around, you'd definitely use memory + handles, but usually when it's SyncFlush reporting the memory issue it's due to handles. Basically the graphics stack at some point is commanded to create the bitmap and can't create the handle to it and allocates a handle. I guess if your bitmaps were very large then the failed creation due to memory would be fine in terms of the rest of the program execution and you might get the same error coming up from the stack. I'll try to find the code for that portion when I get to work on Monday and see what it does exactly.

The traditional scenario I think is lots of bitmaps that are smaller in size (icons, etc). We've seen this in Visual Studio before sometimes introduced by extensions, sometimes by bugs in new code. Hopefully the GC will be more responsive with the current changes, but you might just be stuck forcing the collect.

# ? Aug 27, 2016 05:44

amotea: Mar 23, 2008; Grimey Drawer

Mister Duck posted:

The traditional scenario I think is lots of bitmaps that are smaller in size (icons, etc). We've seen this in Visual Studio before sometimes introduced by extensions, sometimes by bugs in new code. Hopefully the GC will be more responsive with the current changes, but you might just be stuck forcing the collect.

Alright cheers.

ljw1004 posted:

I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science?

I really like F# and use it whenever I can, but for a very large codebase it's currently unworkable because tooling is meh. If it had full R# support I think we wouldn't need C# anymore. So mostly tooling IMO, but I'm talking Resharper level tooling so that's probably not very realistic.

# ? Aug 27, 2016 15:21

Gul Banana: Nov 28, 2003

talking the language maintainers into using a multipass compiler and allowing unordered files would be nice :-(

# ? Aug 27, 2016 17:14

rarbatrol: Apr 17, 2011; Hurt//maim//kill.

amotea posted:

I really like F# and use it whenever I can, but for a very large codebase it's currently unworkable because tooling is meh. If it had full R# support I think we wouldn't need C# anymore. So mostly tooling IMO, but I'm talking Resharper level tooling so that's probably not very realistic.

Yeah, switching from C# to F# at work feels like going back to working with notepad sometimes.

# ? Aug 27, 2016 18:46

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

rarbatrol posted:

Yeah, switching from C# to F# at work feels like going back to working with notepad sometimes.

I would be pushing more F# at work if the tooling was better.

Gul Banana posted:

talking the language maintainers into using a multipass compiler and allowing unordered files would be nice :-(

I think this is explicitly not a goal, and type providers make it harder than it should be even if they wanted to. The fact you end up with so much more actual functionality in each file (single line data type declarations etc.) is meant to make it less of a problem than in a C# codebase.

edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc.

Destroyenator fucked around with this message at 13:32 on Aug 28, 2016

# ? Aug 28, 2016 13:24

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Destroyenator posted:

edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc.

Well there is a community linter, it's integrated in the F# Power Tools. But I agree that an official MS style guide would make a much better impression on CTOs and assorted suits.

# ? Aug 28, 2016 14:06

Gul Banana: Nov 28, 2003

Destroyenator posted:

I think this is explicitly not a goal

right, that's why i say "talk into". it's not something they don't have the manpower for or w/e, but rather an incorrect choice they've made

or at least: incorrect for widescale adoption, use in large-team software, etc. separate development of components without source janitoring is absolutely crucial in that context

# ? Aug 28, 2016 15:53

smarion2: Apr 22, 2010

Thank you goons for suggesting learning Linq. The lamba kind of scared me at first since it looked so different from the object oriented approach I've been accustomed to but it ended up being much easier than I thought it would be. I'll be sure to be incorporating this more in my code from now on!

# ? Aug 28, 2016 17:14

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

NihilCredo posted:

Well there is a community linter, it's integrated in the F# Power Tools. But I agree that an official MS style guide would make a much better impression on CTOs and assorted suits.

Ah nice, I wasn't aware of that. For us it's about getting a C# developer from another team comfortable with opening, reading and making small changes to an F# project. Your points about bundling the compiler, Power Tools and some decent templates in with the standard VS install are spot on.

# ? Aug 28, 2016 17:59

amotea: Mar 23, 2008; Grimey Drawer

Gul Banana posted:

right, that's why i say "talk into". it's not something they don't have the manpower for or w/e, but rather an incorrect choice they've made

or at least: incorrect for widescale adoption, use in large-team software, etc. separate development of components without source janitoring is absolutely crucial in that context

Isn't this more about people coming in with the wrong attitude and unwilling to learn how to properly separate components? Creating properly seperatated components in C# with large teams requires janitoring wrt. building, packages etc. anyway.

Destroyenator posted:

edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc.

Something like this http://fsharp.org/specs/component-design-guidelines/ ?

smarion2 posted:

Thank you goons for suggesting learning Linq. The lamba kind of scared me at first since it looked so different from the object oriented approach I've been accustomed to but it ended up being much easier than I thought it would be. I'll be sure to be incorporating this more in my code from now on!

LINQ is also a big help to move towards a more functional and immutable style of programming BTW. Try to use ImmutableList instead of List from now on and try not to write regular for/foreach loops anymore, it'll decrease the complexity of your code.

amotea fucked around with this message at 13:17 on Aug 29, 2016

# ? Aug 29, 2016 13:14

spiderlemur: Nov 6, 2010

Dumb MVC question time:

What's the best way to avoid using Model objects inside ViewModels even though it's convenient because I need multiple properties from that model?

The reason I want to avoid putting the model inside the ViewModel definition is so I can test the code later and insert whatever I want for data. It's also a large database call as this particular model object has a lot of properties and further dependencies via other model objects in it's repository. I don't need 300 lines of SQL for three properties.

Thinking about what I just wrote, I'm kind of screwed anyway since I have to query for the massive object to retrieve any of it's properties anyway (as far as I know).

Is there a better pattern I can be using for returning minimal amounts of data rather than huge complex objects and the queries associated with them?

# ? Aug 30, 2016 03:47

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

spiderlemur posted:

Dumb MVC question time:

What's the best way to avoid using Model objects inside ViewModels even though it's convenient because I need multiple properties from that model?

The reason I want to avoid putting the model inside the ViewModel definition is so I can test the code later and insert whatever I want for data. It's also a large database call as this particular model object has a lot of properties and further dependencies via other model objects in it's repository. I don't need 300 lines of SQL for three properties.

Thinking about what I just wrote, I'm kind of screwed anyway since I have to query for the massive object to retrieve any of it's properties anyway (as far as I know).

Is there a better pattern I can be using for returning minimal amounts of data rather than huge complex objects and the queries associated with them?

Share some code, I'm not sure what the problem that you're trying to solve is.

# ? Aug 30, 2016 04:01

spiderlemur: Nov 6, 2010

Ithaqua posted:

Share some code, I'm not sure what the problem that you're trying to solve is.

code:

public class UserStatus
{
	public Guid ID { get; set; }
	public string Name { get; set; }
}

public class Person
{
	public Guid ID { get; set; }

	public string FirstName
	public string LastName
	
	public Status UserStatus { get; set; }
	.. a ton of other objects I don't care about. There are around 30 and they all have their own table in EF.
}

public List<UserStatus> GetUserStatuses
{
	return DB.UserStatuses.ToList();
}

public List<Person> GetAllPersons()
{
	return DB.Persons.ToList();
}

public class Repository
{
	public List<Person> GetAllPersons()
	{
		return DB.Persons.ToList();
	}
}

public class MyViewModel
{
        public IEnumerable<Person> Persons { get; set; }
	public IEnumerable<UserStatus> UserStatuses { get; set; }
}

in some view:

@foreach (var status in Model.UserStatuses)
{
	// add a column based on the .Name property of this object.
}

// put all Person objects in their respective column (based comparing the Model with the one inside their Person object)

// page let's them move that person between columns (kanban board) which then posts back and changes their UserStatus depending on the ID.

Problems:

1) How do I unit test this? There are no interfaces on the objects and even so the Person object has 30+ properties associated with it that'd I'd have to implement with some mock object if I filled it in. It's also tied to Identity Framework by checking the UserID when the database is initialized inside of a controller.

2) Isn't this a giant query? I'm grabbing every UserStatus in the database and displaying it on the page, which seems fine, it has two properties and nothing linked to it. But what about the Person I'm comparing it to to determine which column to put it in on my page? I have to grab every single one out of the database to make this check. Isn't EF going to grab every property of every object (a lot of table joins) on that Person when I really only care about one? It seems bad because a lot of information is being passed into the View when I only use or care about 2% of it in the page.

Still kind of a poo poo post, but hopefully that helps a bit.

# ? Aug 30, 2016 04:24

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

spiderlemur posted:

code:
public class UserStatus
{
	public Guid ID { get; set; }
	public string Name { get; set; }
}

public class Person
{
	public Guid ID { get; set; }

	public string FirstName
	public string LastName
	
	public Status UserStatus { get; set; }
	.. a ton of other objects I don't care about. There are around 30 and they all have their own table in EF.
}

public List<UserStatus> GetUserStatuses
{
	return DB.UserStatuses.ToList();
}

public List<Person> GetAllPersons()
{
	return DB.Persons.ToList();
}

public class Repository
{
	public List<Person> GetAllPersons()
	{
		return DB.Persons.ToList();
	}
}

public class MyViewModel
{
        public IEnumerable<Person> Persons { get; set; }
	public IEnumerable<UserStatus> UserStatuses { get; set; }
}

in some view:

@foreach (var status in Model.UserStatuses)
{
	// add a column based on the .Name property of this object.
}

// put all Person objects in their respective column (based comparing the Model with the one inside their Person object)

// page let's them move that person between columns (kanban board) which then posts back and changes their UserStatus depending on the ID.
Problems:

1) How do I unit test this? There are no interfaces on the objects and even so the Person object has 30+ properties associated with it that'd I'd have to implement with some mock object if I filled it in. It's also tied to Identity Framework by checking the UserID when the database is initialized inside of a controller.

2) Isn't this a giant query? I'm grabbing every UserStatus in the database and displaying it on the page, which seems fine, it has two properties and nothing linked to it. But what about the Person I'm comparing it to to determine which column to put it in on my page? I have to grab every single one out of the database to make this check. Isn't EF going to grab every property of every object (a lot of table joins) on that Person when I really only care about one? It seems bad because a lot of information is being passed into the View when I only use or care about 2% of it in the page.

Still kind of a poo poo post, but hopefully that helps a bit.

1) You wouldn't mock the Person class, you'd mock the repository that returns them. Then you'd construct those Persons that you're using for your test however you want. Yes, you'll need to add interfaces and use standard DI techniques to provide an instance (whether it's a mock implementation of your Repository or a real one) at runtime. If the property isn't relevant to your test, leave it as null or default. If your Person object touches the database, that's bad. Don't do that.

In general, once you know the typical techniques for unit testing, the statement, "This is hard to test" is almost always followed by "...because it's badly designed". The answer to "How do I unit test this?" then becomes "Fix the bad design." Sometimes that requires working with what you have and writing some awful integration tests to give you a safety net while you're fixing the design. That's okay.

2) :shrug:

I don't use EF frequently.

# ? Aug 30, 2016 05:22

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 08:14

BlackMK4: Aug 23, 2006; wat.; Megamarm

Is there a decent resource for diving into MVC5/6? Books are fine.

# ? Aug 30, 2016 05:48

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »