.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 »

Calidus: Oct 31, 2011; Stand back I'm going to try science!

I have given up on my issue. Has anyone tried using Win10 as a .Net Dev environment yet?

# ? Aug 3, 2015 17:52

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 10:20

EssOEss: Oct 23, 2006; 128-bit approved

I am using Windows 10 with great success so far. No complaints. Anything specific you are worried about?

# ? Aug 3, 2015 19:01

Calidus: Oct 31, 2011; Stand back I'm going to try science!

EssOEss posted:

I am using Windows 10 with great success so far. No complaints. Anything specific you are worried about?

I have to target .Net 4 and a couple of xp machines(yes it is terrible I know) just worried oddities nothing really specific.

# ? Aug 3, 2015 19:06

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

I'm trying to do some work on a RESTful API and I have a requirement for an endpoint that will calculate the cost of a theoretical purchase, but not actually make the purchase. I'm not sure how I can do this in a RESTful way. I assume it's a GET, since it doesn't persist anything at all on the server side, so would an endpoint like businesses/{id}/quote make sense? My thinking is that essentially the client-side is asking the server-side for a quote based on particular purchase parameters.

Edit:
Another question: In order to make the API simpler to use internally, I'd like to create simple DTOs for making requests and receiving responses. This way the consuming application can see what data is expected by looking at the DTO that corresponds to the API call they're making. For example, business/{id} would have a DTO that simply contains an Id property, like this:

code:

public class GetBusinessByIdRequest
{
    public int Id { get; set; }
}

This seems like overkill by this example, but it becomes quite useful for endpoints that require much more information, or PUT endpoints where I'd like to make it explicit which fields can actually be submitted for an update.

I guess what I'm asking is, is this the correct way to go about this?

putin is a cunt fucked around with this message at 04:13 on Aug 4, 2015

# ? Aug 4, 2015 03:14

Gul Banana: Nov 28, 2003

it doesn't sound like anything is gained by trying to make this particular api REST. it's not naturally resource based and request-object mapping is at odds with hateoas navigation.

is there some reason you want to use a RESTful style instead of just an RPC-style http api?

# ? Aug 4, 2015 05:18

Mr Shiny Pants: Nov 12, 2012

Gul Banana posted:

it doesn't sound like anything is gained by trying to make this particular api REST. it's not naturally resource based and request-object mapping is at odds with hateoas navigation.

is there some reason you want to use a RESTful style instead of just an RPC-style http api?

An order can be a resource, by a bit of a stretch. And it seems that in the whole REST api discussion the hateoas stuff gets forgotten really quickly. Probably because it is pretty hard to wrap your head around instead of just using HTTP verbs on collections or single items.

This is a good explanation of hateoas navigation : https://vimeo.com/41763224

You could treat your quote as a property of a order resource that gets created when you make an order or add something to your basket and have an URL that comes back to the client as /orders/orderguid/quote.

# ? Aug 4, 2015 05:53

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Gul Banana posted:

it doesn't sound like anything is gained by trying to make this particular api REST. it's not naturally resource based and request-object mapping is at odds with hateoas navigation.

is there some reason you want to use a RESTful style instead of just an RPC-style http api?

The rest of the API is resource-based, it's only this one method that I'm struggling with. Here's some more of the endpoints to show you what I mean:

code:

Endpoint                         | Method   | Input                                | Output         
------------------------------------------------------------------------------------------------------
businesses                       | GET      | --                                   | List<Businesses>
businesses                       | POST     | --                                   | --
businesses/{id}                  | GET      | URL:  id (int)                       | Business
businesses/{id}                  | PUT      | URL:  id (int)                       | --
businesses/{id}                  | DELETE   | URL:  id (int)                       | --
downloads                        | GET      | --                                   | List<Download>
downloads/{id}                   | GET      | URL:  id (int)                       | Download
downloads/{id}/digital-signature | POST     | URL:  id (int)                       | --

Almost all of the operations we're interesting in performing are CRUD style operations on resources - those that aren't I think I can turn them into resource-based operations by thinking about them differently. For example, perhaps instead of a "quote", what I really want to do is put the price on a "products" resource, get the products from the API and calculate the total client-side. (Or do something similar to what Mr Shiny Pants suggested.)

But I'm still interested in the request object thing. Let's look at downloads/{id}/digital-signature for example. To create a digital signature, I really don't need ANY information from the client other than the DownloadId, which is supplied in the URL. So would it make sense to accept a POST request with no body, even though calling a GET on (for example) digital-signatures/{id} would return a DigitalSignature instance? In other words, is there any rule that says I need to POST what I would expect to GET? If so, doesn't that mean a whole lot of redundant information?

putin is a cunt fucked around with this message at 06:54 on Aug 4, 2015

# ? Aug 4, 2015 06:48

Mr Shiny Pants: Nov 12, 2012

The Wizard of Poz posted:

The rest of the API is resource-based, it's only this one method that I'm struggling with. Here's some more of the endpoints to show you what I mean:
code:
Endpoint                         | Method   | Input                                | Output         
------------------------------------------------------------------------------------------------------
businesses                       | GET      | --                                   | List<Businesses>
businesses                       | POST     | --                                   | --
businesses/{id}                  | GET      | URL:  id (int)                       | Business
businesses/{id}                  | PUT      | URL:  id (int)                       | --
businesses/{id}                  | DELETE   | URL:  id (int)                       | --
downloads                        | GET      | --                                   | List<Download>
downloads/{id}                   | GET      | URL:  id (int)                       | Download
downloads/{id}/digital-signature | POST     | URL:  id (int)                       | --
Almost all of the operations we're interesting in performing are CRUD style operations on resources - those that aren't I think I can turn them into resource-based operations by thinking about them differently. For example, perhaps instead of a "quote", what I really want to do is put the price on a "products" resource, get the products from the API and calculate the total client-side. (Or do something similar to what Mr Shiny Pants suggested.)

But I'm still interested in the request object thing. Let's look at downloads/{id}/digital-signature for example. To create a digital signature, I really don't need ANY information from the client other than the DownloadId, which is supplied in the URL. So would it make sense to accept a POST request with no body, even though calling a GET on (for example) digital-signatures/{id} would return a DigitalSignature instance? In other words, is there any rule that says I need to POST what I would expect to GET? If so, doesn't that mean a whole lot of redundant information?

I think what Gul Banana is getting at is that this is not really REST. These are just some endpoints where you can get stuff over HTTP. ( Mind you this seems to be they way almost everyone does this, so I don't know if this might be the new REST. Sort of like with language, if enough people use a word the wrong way it sort of gets that new meaning.)

To answer your question: GET is for getting stuff, so for the signature in my mind you "GET the signature from a specific Id". So a GET operation on a resource feels like a natural fit. POST is for changing things. Or do you do anything after the signature generation with the signature on the server? If so, a POST would be more appropriate because you change the resource.

I would make the order a resource:

User selects something (creates order if you will): POST --> /orders, return 201 Created <-- /orders/ORDERID.
Quote: GET /orders/ORDERID/quote, return 200 OK
Add something: PUT --> /orders/ORDERID, return 200 OK.

Now if you use the hateoas style you can put the options for the resource in the response. So if you create the order you get a response with the possible URLs you can use following the state of the order creation. Let's say you create the order using POST, the reply could contain the the following reply: Change Order PUT objectid /orders/ORDERID, Checkout /checkout/ORDERID, Quote -> GET /orders/ORDERID/quote.

If you parse these responses on the client you could traverse your entire api using just the responses. ( The Hypermedia part )

# ? Aug 4, 2015 07:41

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Mr Shiny Pants posted:

I think what Gul Banana is getting at is that this is not really REST. These are just some endpoints where you can get stuff over HTTP. ( Mind you this seems to be they way almost everyone does this, so I don't know if this might be the new REST. Sort of like with language, if enough people use a word the wrong way it sort of gets that new meaning.)

To answer your question: GET is for getting stuff, so for the signature in my mind you "GET the signature from a specific Id". So a GET operation on a resource feels like a natural fit. POST is for changing things. Or do you do anything after the signature generation with the signature on the server? If so, a POST would be more appropriate because you change the resource.

I would make the order a resource:

User selects something (creates order if you will): POST --> /orders, return 201 Created <-- /orders/ORDERID.
Quote: GET /orders/ORDERID/quote, return 200 OK
Add something: PUT --> /orders/ORDERID, return 200 OK.

Now if you use the hateoas style you can put the options for the resource in the response. So if you create the order you get a response with the possible URLs you can use following the state of the order creation. Let's say you create the order using POST, the reply could contain the the following reply: Change Order PUT objectid /orders/ORDERID, Checkout /checkout/ORDERID, Quote -> GET /orders/ORDERID/quote.

If you parse these responses on the client you could traverse your entire api using just the responses. ( The Hypermedia part )

Can you clarify what it is about the endpoints I posted that causes you to consider them not-RESTful? I'm really kind of new to this RESTful stuff so I'm trying to understand.

Edit: I've just been doing some follow-up reading and I think I understand now. But to my naive eye, it looks as though virtually all of the "RESTful" APIs that I know of are not actually RESTful, if you accept HATEOAS as a prerequisite for RESTfulness. Is this right?

putin is a cunt fucked around with this message at 07:52 on Aug 4, 2015

# ? Aug 4, 2015 07:44

Mr Shiny Pants: Nov 12, 2012

The Wizard of Poz posted:

Can you clarify what it is about the endpoints I posted that causes you to consider them not-RESTful? I'm really kind of new to this RESTful stuff so I'm trying to understand.

You should watch the video I posted above, otherwise it will take me all day to post a reply detailing all the nuances.

Not that I mind, but the presentation is better.

# ? Aug 4, 2015 07:51

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Mr Shiny Pants posted:

You should watch the video I posted above, otherwise it will take me all day to post a reply detailing all the nuances.

Not that I mind, but the presentation is better.

Thanks, I will definitely check it out.

# ? Aug 4, 2015 07:53

Funking Giblet: Jun 28, 2004; Jiglightful!

Remember.
Post = new item
Put = replace an item (either insert in existing position and move the surrounding indexes, or replace record so old one no longer exists / is archived.
Patch = update fields on item.

# ? Aug 4, 2015 07:54

Mr Shiny Pants: Nov 12, 2012

The Wizard of Poz posted:

Thanks, I will definitely check it out.

Hope you like it, I thought it was pretty great.

# ? Aug 4, 2015 08:09

Gul Banana: Nov 28, 2003

i wasn't very clear before due to phoneposting, but mr. shiny pants has it right. there's nothing wrong with "just some endpoints where you can get stuff over HTTP" though- the implication is that it then doesn't matter much what the Right Way is, because it's whatever you make up.

people sometimes talk about "levels" of REST these days, which are like
level 1 - you're using http methods and json
level 2 - the api is oriented around resources rather than calls
level 3 - client application state transitions via discovered hypermedia

each brings you closer to a model which is in theory highly scalable, evolvable, etc, but is not actually necessary, particularly if you have only a single client and server.

# ? Aug 4, 2015 10:58

Gul Banana: Nov 28, 2003

The Wizard of Poz posted:

Edit: I've just been doing some follow-up reading and I think I understand now. But to my naive eye, it looks as though virtually all of the "RESTful" APIs that I know of are not actually RESTful, if you accept HATEOAS as a prerequisite for RESTfulness. Is this right?

this is correct, the common definition has drifted & there's a lot of ongoing debate about the term's utility. if vagueblogging and subtweeting rise to the level of 'debate'.

# ? Aug 4, 2015 10:59

ninjeff: Jan 19, 2004

Gul Banana posted:

i wasn't very clear before due to phoneposting, but mr. shiny pants has it right. there's nothing wrong with "just some endpoints where you can get stuff over HTTP" though- the implication is that it then doesn't matter much what the Right Way is, because it's whatever you make up.

people sometimes talk about "levels" of REST these days, which are like
level 1 - you're using http methods and json
level 2 - the api is oriented around resources rather than calls
level 3 - client application state transitions via discovered hypermedia

each brings you closer to a model which is in theory highly scalable, evolvable, etc, but is not actually necessary, particularly if you have only a single client and server.

This is a pretty readable intro to the "levels" concept Gul Banana mentioned

# ? Aug 4, 2015 11:44

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

The Wizard of Poz posted:

Can you clarify what it is about the endpoints I posted that causes you to consider them not-RESTful? I'm really kind of new to this RESTful stuff so I'm trying to understand.

Edit: I've just been doing some follow-up reading and I think I understand now. But to my naive eye, it looks as though virtually all of the "RESTful" APIs that I know of are not actually RESTful, if you accept HATEOAS as a prerequisite for RESTfulness. Is this right?

My advice is to not worry so much about what is and what isn't RESTful. That bikeshedding argument has wasted enough developer time already. HATEOAS is a grandiose ideal that in practice very few people follow because the technical benefits are miniscule.

The main benefit of designing your API around resources is that you're following the principle of least surprise. Your API will look similar to everyone else's API, which makes it easier to discover and understand. But, if something doesn't fit into a resource model, don't strain to make it fit. Make it a one-off POST method and call it a day.

# ? Aug 4, 2015 14:31

Dietrich: Sep 11, 2001

Can't disagree more. One of the hardest things to design for with APIs is versioning and change control, and HATEOAS is a very elegant way to to deal with that.

# ? Aug 4, 2015 14:38

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I'm suddenly a little bit confused about where to implement INotifyPropertyChanged when using MVVM. In the code below the contents of the label are updated whenever I re-select an item in the ListBox, but not as I edit the TextBoxes--and the ListBox strings themselves are never updated. I know this is because the properties in Model don't notify anyone that they've changed, being a POCO. The question is, should I be implementing INotifyPropertyChanged on models for situations like this, or using some other way to get the ListBox and Label to update as I type (or at least as I change focus from the TextBoxes, given how updates on those seem to only happen on LostFocus by default)? Or a different way to bind the TextBoxes (or other edit fields in other applications) altogether, maybe?

C# code:

class Model
{
  public string A {get; set;}
  public string B {get; set;}

  public override string ToString()
  {
    return A + "," + B;
  }
}

C# code:

class ViewModel : ViewModelBase // INotifyPropertyChanged -- SetField() mainly	 
{
  public ViewModel()
  {
    Models = new ObservableCollection<Model>();
    Models.Add(new Model { A = "123", B = "abc" });
    Models.Add(new Model { A = "456", B = "def" });
  }

  public ObservableCollection<Model> Models {get; set;}
  Model _SelectedModel;
  public Model SelectedModel
  {
    get { return _SelectedModel; }
    set { SetField(ref _SelectedModel, value); IsModelSelected = value != null; }
  }

  bool _IsModelSelected;
  public bool IsModelSelected
  {
    get { return _IsModelSelected; }
    set { SetField(ref _IsModelSelected, value); }
  }

  public RelayCommand AddCommand
  {
    get
    {
      return new RelayCommand(x =>
      {
        Model m = new Model();
        Models.Add(m);
        SelectedModel = m;
      });
    }
  }
}

XML code:

<Window ...>
  <StackPanel>
    <Button Content="Add New" Command="{Binding AddCommand}" />
    <ListBox Height="100" ItemsSource="{Binding Models}" SelectedItem="{Binding SelectedModel}"/>
    <TextBox Text="{Binding SelectedModel.A}" IsEnabled="{Binding IsModelSelected}" />
    <TextBox Text="{Binding SelectedModel.B}" IsEnabled="{Binding IsModelSelected}" />
    <Label Content="{Binding SelectedModel}"/>
  </StackPanel>
</Window>

Ciaphas fucked around with this message at 18:14 on Aug 4, 2015

# ? Aug 4, 2015 18:08

crashdome: Jun 28, 2011

Quick cursory glance tells me you'll need them on your Model as well.

qe: I follow this pattern as well. I use EF6 and my templates automatically implement the interface (among others) on my models that are auto-generated from the DB. I manually implement it through inheritance for models that are not tied to EF. Some will argue that you should treat your VM more as a model with properties of itself bound directly and then have them modify a POCO Model when changed as a sort of DTO. I prefer to pass my models directly to the UI for binding as you did because EF does a pretty good job (in small projects at least) of data/biz layer separation.

crashdome fucked around with this message at 18:25 on Aug 4, 2015

# ? Aug 4, 2015 18:17

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

crashdome posted:

Some will argue that you should treat your VM more as a model with properties of itself bound directly and then have them modify a POCO Model when changed as a sort of DTO.

This is what I was taught as well, now that you put it into words. :v:

I tried implementing INotifyPropertyChanged in Model (or rather inheriting my ObservableBase abstract, same thing), but was getting the same results of the Label only updating when I re-selected, and the ListBox never updating. Then I realized the problem: those two are bound to Model objects, not parts of the Model, so they aren't notified when only parts of the Model change.

So what's the solution to get the ListBox entries and Label to immediately update? My first guess was to treat Model objects as immutable, and create a new one every time a component value changes (thus triggering PropertyChanged) but that sounds like nightmarishly poor performance. (Not that performance is important at all in this use case, but it still makes me cringe.)

# ? Aug 4, 2015 18:49

Mr Shiny Pants: Nov 12, 2012

Ciaphas posted:

This is what I was taught as well, now that you put it into words.

I tried implementing INotifyPropertyChanged in Model (or rather inheriting my ObservableBase abstract, same thing), but was getting the same results of the Label only updating when I re-selected, and the ListBox never updating. Then I realized the problem: those two are bound to Model objects, not parts of the Model, so they aren't notified when only parts of the Model change.

So what's the solution to get the ListBox entries and Label to immediately update? My first guess was to treat Model objects as immutable, and create a new one every time a component value changes (thus triggering PropertyChanged) but that sounds like nightmarishly poor performance. (Not that performance is important at all in this use case, but it still makes me cringe.)

I don't implement INPC on my Model. The VM encapsulates the model and implements INPC on the setters that put them through the Model.

Personally I don't like having INPC on my model, I've had problems serializing my Model because of Observable Collections and the like.

The Models in the ListBox should also be encapsulated by VMs. So you have an Observable Collection that holds VMs that implement INPC.

Mr Shiny Pants fucked around with this message at 19:25 on Aug 4, 2015

# ? Aug 4, 2015 19:20

crashdome: Jun 28, 2011

I just noticed this... try "SelectedValue" instead of "SelectedItem"

Here's an example of one of my ListBoxes:

XML code:

<ListBox Margin="0,10,334.333,11.667" 
     ItemsSource="{Binding StockRolls}" 
     DisplayMemberPath="Description" 
     SelectedValue="{Binding SelectedStockRollSize}"/>

Mr Shiny Pants posted:

I don't implement INPC on my Model. The VM encapsulates the model and implements INPC on the setters that put them through the Model.

Personally I don't like having INPC on my model, I've had problems serializing my Model because of Observable Collections and the like.

This is a perfectly fine pattern to use. I personally hate having POCO models because of the redundancy and extra work required in the ViewModel. I feel it strips out "too much" and places every responsibility into the VM except values. My Models handle values, validation, notification, and change tracking. My VM simply handles bringing all that to the UI (as it should).

e: It took me a moment to find this but, I like the top two answers and the comments which plainly set out the arguments for/against: Link
I remember a blog post talking about it also. Can't find it.

The big reason is if your models are changed via some other service or whatever... how do you notify the VM something has changed? This happens a lot in my applications.

crashdome fucked around with this message at 20:08 on Aug 4, 2015

# ? Aug 4, 2015 19:24

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

In my experience, implementing INPC on your POCO model is the kind of thing that's a very convenient solution for your current problem and a nightmare for your future ones. As your application grows in complexity, you'll just keep stringing events and notifications all over your architecture and figuring out how it all fits together will become a huge pain in the rear end.

Maybe you're better at it then I am, though.

# ? Aug 4, 2015 20:13

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

GrumpyDoctor posted:

In my experience, implementing INPC on your POCO model is the kind of thing that's a very convenient solution for your current problem and a nightmare for your future ones. As your application grows in complexity, you'll just keep stringing events and notifications all over your architecture and figuring out how it all fits together will become a huge pain in the rear end.

Maybe you're better at it then I am, though.

In terms of POCO pollution, INPC isn't too bad, and there might be other places in the application that would like to know when properties change. It's a light enough interface that I don't feel too dirty implementing it on POCOs.

# ? Aug 4, 2015 20:15

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

Ithaqua posted:

In terms of POCO pollution, INPC isn't too bad, and there might be other places in the application that would like to know when properties change. It's a light enough interface that I don't feel too dirty implementing it on POCOs.

The problem I was having was that one of those other listeners would acquire its own set of listeners, and so it now needed INPC, and then maybe one of its listeners needed INPC, and oh poo poo now maybe I've got a notification cycle, but only in this one case and I can break it by only selectively firing PropertyChanged, or maybe checking whether it was fired with an empty string or the specific property I'm checking, but oh now this other case exists which breaks that logic, and these aren't even just dumb models anymore, and :suicide:

So I decided I needed very clearly defined notification channels. Again, though, I might just not have the mindset to make it work.

# ? Aug 4, 2015 20:38

crashdome: Jun 28, 2011

GrumpyDoctor posted:

As your application grows in complexity, you'll just keep stringing events and notifications all over your architecture and figuring out how it all fits together will become a huge pain in the rear end.

It's not that bad if you are passing your models to the UI instead of having the VM hook up an event on the model and changing some wrapping property. I haven't ever needed to manually hook an INPC event yet when I follow the pattern as Ciaphas has shown.

I DO need to be able to have a service modify several models as a result of a change in state or the result of an action and bubble it up to the VM. I could use Messages... but why? Talk about inflating your application as a whole to keep some minor thing skinny.

# ? Aug 4, 2015 20:38

Mr Shiny Pants: Nov 12, 2012

crashdome posted:

The big reason is if your models are changed via some other service or whatever... how do you notify the VM something has changed? This happens a lot in my applications.

I don't have this particular use case but:

I would treat the service updating my Models as just another user accessing the application through the GUI I think. So it would go through the viewmodel for updates like any other user of my system.

I don't know, came to mind to do it this way, don't know the feasibility of this in your situation.

# ? Aug 4, 2015 21:31

Mr Shiny Pants: Nov 12, 2012

This is probably a long shot, but here goes:

Does anyone have experience using BouncyCastle with Mono on Linux? I am getting and error trying to convert my PKCS12 container into a X509Certificate2.

# ? Aug 4, 2015 22:31

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

Mr Shiny Pants posted:

I don't have this particular use case but:

I would treat the service updating my Models as just another user accessing the application through the GUI I think. So it would go through the viewmodel for updates like any other user of my system.

I don't know, came to mind to do it this way, don't know the feasibility of this in your situation.

This is what I usually do, but you have to make your peace with some duplicated properties between model and viewmodel.

Mr Shiny Pants posted:

Does anyone have experience using BouncyCastle with Mono on Linux? I am getting and error trying to convert my PKCS12 container into a X509Certificate2.

What error? And does it work in Windows?

# ? Aug 4, 2015 22:42

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Bognar posted:

This is what I usually do, but you have to make your peace with some duplicated properties between model and viewmodel.

At this rate I might have to make peace too, because oh my god trying to get these goddamned UI elements to update when only a component of their bound data changes is a loving nightmare. I've been agonizing over this for hours and I'm no closer to getting that ListBox to update itself when the textboxes change :cry:

(edit) Like when I go back and forth between items in the ListBox, the textblocks correctly reflect their updated contents, but the string in the ListBox entry itself never ever udpates.

Ciaphas fucked around with this message at 23:06 on Aug 4, 2015

# ? Aug 4, 2015 23:02

crashdome: Jun 28, 2011

Mr Shiny Pants posted:

I don't have this particular use case but:

I would treat the service updating my Models as just another user accessing the application through the GUI I think. So it would go through the viewmodel for updates like any other user of my system.

I don't know, came to mind to do it this way, don't know the feasibility of this in your situation.

Mi
Not really feasible. For example, I have a service which updates a business model every 250ms. It does so not only because I need to display a voltage level from a power unit I am communicating with on screen, I also (when not displaying it on screen) need to verify it's state constantly during certain procedures.

I need to know within a fraction of a second if the unit is suddenly powered down or has a massive change in voltage due to a failure or an operators involvement.

That's an extreme case for sure but, having everything work through a ViewModel's properties to change the state of a POCO model makes me ask the question: For what purpose does the model serve?

E: Vvvvv not really... It's a long standing MVVM debate that I feel is dependant on the application needs. It's certainly swung one way for my projects but, ymmv.

crashdome fucked around with this message at 02:29 on Aug 5, 2015

# ? Aug 5, 2015 01:09

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Wait a sec did I accidentally open a :can:

earlier with my confusion about INPC implementation location? :ohdear:

# ? Aug 5, 2015 02:12

GoodCleanFun: Jan 28, 2004

Mr Shiny Pants posted:

I don't implement INPC on my Model. The VM encapsulates the model and implements INPC on the setters that put them through the Model.

Personally I don't like having INPC on my model, I've had problems serializing my Model because of Observable Collections and the like.

The Models in the ListBox should also be encapsulated by VMs. So you have an Observable Collection that holds VMs that implement INPC.

Agree completely although I like to use IDataErrorInfo for setting my model's properties where applicable. This is end game WPF.

# ? Aug 5, 2015 02:58

Mr Shiny Pants: Nov 12, 2012

Bognar posted:

This is what I usually do, but you have to make your peace with some duplicated properties between model and viewmodel.

What error? And does it work in Windows?

It works on Windows, the problem is that BouncyCastle generates ASN1 that has infinite length encoding. Mono's ASN decoder can't handle this.

So I've tried a PKCS12 utilitity within BouncyCastle that should re-encode it into finite length with DERoutputstream but no dice. I've opened a bug on this.

Window's Crypto Api supports both, ASN1 with infinite length and re-encoding to DER.

Ciaphas posted:

Wait a sec did I accidentally open a earlier with my confusion about INPC implementation location?

Nah, this stuff is pretty new for me too, and writing it down makes me understand it better. As long we're not calling each other stupid I think this is a wonderful discussion.

crashdome posted:

That's an extreme case for sure but, having everything work through a ViewModel's properties to change the state of a POCO model makes me ask the question: For what purpose does the model serve?

Well my viewmodels are adorned with extra properties that are not needed on the model ( selected item, percent complete, etc, etc. ) so in that way you have a clear delineation between what should be on the model and what should be on the viewmodel. To be honest when I started this MVVM stuff everything felt really convoluted and complex and I wondered this myself, but the above approach seems to work. I have a pretty complex viewmodel which has extra logic for calculating properties that I only need to use in the GUI, my Model on the other hand is pretty simple, regular properties and lists without any scaffolding for the GUI. This means that I can serialize my Model in one statement to a JSON stream. I am not an expert by any stretch of the imagination though.

crashdome posted:

Mi
Not really feasible. For example, I have a service which updates a business model every 250ms. It does so not only because I need to display a voltage level from a power unit I am communicating with on screen, I also (when not displaying it on screen) need to verify it's state constantly during certain procedures.
I need to know within a fraction of a second if the unit is suddenly powered down or has a massive change in voltage due to a failure or an operators involvement.

I don't think going through another setter of another class on the same machine in the same application is going to add that much overhead to be honest. Not in the range of 100s of milliseconds. Could be though, I never worked with these time constraints, just a feeling.

# ? Aug 5, 2015 08:19

crashdome: Jun 28, 2011

Mr Shiny Pants posted:

I don't think going through another setter of another class on the same machine in the same application is going to add that much overhead to be honest. Not in the range of 100s of milliseconds. Could be though, I never worked with these time constraints, just a feeling.

I see your point. I don't think it is invalid. I guess I've always approached it from the opposite spectrum of "I have a ViewModel because I have View which I need to display model data." and as a result the View may not always manipulate the entirety of the Model. And in some cases might even combine several types of models in one ViewModel.

To follow my previous example I have a View (UserControl) which has these controls:
- A Display for Voltage
- A Button for toggling power to the unit

Model: On the other side is a model which simply keeps the state of the unit (CurrentVoltage, DesiredVoltage, PowerState (On/Off), etc..)

Service: I have a service which modifies that state and controls access to a Serial Port for reading current state and setting new states in the actual unit through IO.

ViewModel Interface to Service: I have an Interface to that service which is for the View only. It simply exposes the Model for state info and a command with the ability to Toggle the unit On/Off
TestController Interface to Service: I have another interface used by a controller which monitors a test process. This controller is responsible for the more complicated functions of telling it when to read values, change the state if something has changed externally, set a new voltage level, automatic power down in certain cases, and even stop monitoring if the application isn't in certain modes. None of those functions are done by a human being. (Although there is a diagnostic screen for admins which do - I won't get into it in this example).

My ViewModel uses the VM Interface and I - for simplicity - expose the Model as being the "state" of the unit and one simple command. I could certainly use a single property to display voltage on the VM but, I would need to have the Model update the VM somehow. It just seems incredibly easier... and FAR more logical to me that the state is bubbled up to a View through the VM and not from it. My TestController doesn't have to use a ViewModel Interface to interact with the service while exposing all functionality to the ViewModel. In fact, the TestController doesn't even have a view. It's all business logic. So why pollute with something like a "View"Model?

That's how I've been approaching the concept of a ViewModel. It's for a View. You can expose none, some or all of a Model through an Interface (service if you will). For the View.

Again, I'm not arguing that all Models need INPC. I'm just saying there is a certain camp of people that believe it should all be one way and that works great if you are doing something like a web service or serializing, etc.. or a simple data entry (or data view) application. The thought that "every responsibility must go through a viewmodel" is missing the point. The ViewModel - Model culture was to separate responsibility from a model by decoupling view logic from a model. Not all interfaces cluttering up a model are "just for the View" and that models have to be pocos with auto-properties. It severely diminishes the true purpose of a model. By putting everything into a ViewModel you are now severely coupling your business logic to a ViewModel. It is my opinion (with my limited experience with MVVM

) that a ViewModel and Model share responsibility and that the ViewModel should only be responsible for the parts of a model that is for the view.

Maybe I'm a bad programmer but I have a ViewModel which implements several different sets of Interfaces which might interact with multiple types of models.... but I only have that one ViewModel because I only have that one View.

# ? Aug 5, 2015 18:04

Mr Shiny Pants: Nov 12, 2012

crashdome posted:

Maybe I'm a bad programmer but I have a ViewModel which implements several different sets of Interfaces which might interact with multiple types of models.... but I only have that one ViewModel because I only have that one View.

I don't buy it

crashdome posted:

Again, I'm not arguing that all Models need INPC. I'm just saying there is a certain camp of people that believe it should all be one way and that works great if you are doing something like a web service or serializing, etc.. or a simple data entry (or data view) application. The thought that "every responsibility must go through a viewmodel" is missing the point. The ViewModel - Model culture was to separate responsibility from a model by decoupling view logic from a model. Not all interfaces cluttering up a model are "just for the View" and that models have to be pocos with auto-properties. It severely diminishes the true purpose of a model. By putting everything into a ViewModel you are now severely coupling your business logic to a ViewModel. It is my opinion (with my limited experience with MVVM ) that a ViewModel and Model share responsibility and that the ViewModel should only be responsible for the parts of a model that is for the view.

Thanks for writing that and this is also my understanding. My point was more along the lines of: If you treat the service that now directly updates your model as another user, and let it update the model through the View Model you would not need INPC on the Model itself. So if your service polls something and gets it data back you could tell it to use the setters on the View Model instead of directly setting the properties on the Model and needing a way to tell the view the model is updated. This saves you from writing INPC on the model, which is really just framework plumbing.

Never mind though, it was fun to think about something like this.

# ? Aug 5, 2015 20:04

crashdome: Jun 28, 2011

True! and that works. It also then exposes your entire service to the ViewModel and in effect... to the View. This may not be something one may wish to do just to save some plumbing which I think is pretty trivial ~~(since I am not serializing)~~.

e: and serialization isn't even an issue in this example - I was thinking of another use case when I wrote that.

crashdome fucked around with this message at 20:49 on Aug 5, 2015

# ? Aug 5, 2015 20:38

Mr Shiny Pants: Nov 12, 2012

Cool! Those are some good reasons, sounds like a cool project.

In other good news, I have my certificates working on Linux with BouncyCastle and Mono. Yay.
The secret is to use Mono to build the PKCS12 container and convert the BouncyCastle stuff ( keypairs, certificates and RSA key settings ) over to Mono.Security classes.
After you have converted the BC classes to their respective Mono classes you can use the PKCS12 class from Mono.Security to create a PKCS12 container that does not have infinite length ASN1 encoding or invalid data.
After that you can use File.WriteAllBytes to write the PFX with the privatekey and the cer file to disk.

If anyone is interested I can post the code. This took way too long.

# ? Aug 5, 2015 20:45

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 10:20

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Alright, I've completely lost the plot. If binding directly to model properties through the view is bad juju (because it embeds knowledge of the model's internals into the view), and therefore have to have the view bind to viewmodel properties through which the actual data model is updated... then why do model classes exist at all in MVVM?

:saddowns:

# ? Aug 5, 2015 21:00

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

«‹›299 »