|
also i had to write a tfs 2013 xml file thing to deal w/ nuget restore and it touched me in bad places since we had to deal w/ tools being packaged in nuget containers like, maven's been around since 2004. why copy ivy??????
|
# ? Aug 21, 2015 22:44 |
|
|
# ? Jun 7, 2024 09:01 |
|
I have an idea for a web app that I'm thinking of putting together a prototype for. Potentially, it could end up as a real thing. If that did happen to happen, it could maybe have quite a large audience. I have absolutely no realistic idea of numbers though. I am planning to use the MVC framework since that's what I know best for web apps. I've got a few general questions about my approach to this: - The site will need users to have a login, authenticated email address, profile, etc. Is the baked in stuff (ASP.NET Identity I think?) in the MVC framework good enough for this? - Will EF be ok, or does it scale badly? Or are there things I can do to make it scale well? Or should I just gently caress it off and use Dapper? - I might well make a companion mobile app as well - would the best way to do this be to provide a Web API controller to service the app? Or is that more suited to when you want to expose a public API?
|
# ? Aug 24, 2015 09:31 |
|
chippy posted:- The site will need users to have a login, authenticated email address, profile, etc. Is the baked in stuff (ASP.NET Identity I think?) in the MVC framework good enough for this? I think you'll be fine with all three of those. Although I don't personally have experience with EF.
|
# ? Aug 24, 2015 11:03 |
|
Yes, the things you outlined should be perfectly satisfactory for this and are what I would do if I did a project along the lines of what you describe.
|
# ? Aug 24, 2015 14:37 |
|
chippy posted:I have an idea for a web app that I'm thinking of putting together a prototype for. Potentially, it could end up as a real thing. If that did happen to happen, it could maybe have quite a large audience. I have absolutely no realistic idea of numbers though. I am planning to use the MVC framework since that's what I know best for web apps. I've got a few general questions about my approach to this: Those things should scale OK. EF is like 100 times slower than raw SQL but you have to be really huge for this to really be an issue and generally what happens in projects that don't use an ORM is they slowly evolve a buggier, shittier verison of an ORM.
|
# ? Aug 24, 2015 17:15 |
|
chippy posted:I have an idea for a web app that I'm thinking of putting together a prototype for. Potentially, it could end up as a real thing. If that did happen to happen, it could maybe have quite a large audience. I have absolutely no realistic idea of numbers though. I am planning to use the MVC framework since that's what I know best for web apps. I've got a few general questions about my approach to this: I did something similar and used baked in stuff for logins, left EF in place for those, but used PetaPoco for my own data access.
|
# ? Aug 24, 2015 18:35 |
|
I'm writing a plugin for an application, and I want my plugin to modify the application's window title text. I can do this just fine using the main window HWND that the application's plugin API exposes, but the problem is that I'm not notified when the host application changes its own title text, so its changes overwrite mine. Can I use this HWND to somehow detect these title text changes?
|
# ? Aug 24, 2015 23:40 |
|
GrumpyDoctor posted:I'm writing a plugin for an application, and I want my plugin to modify the application's window title text. I can do this just fine using the main window HWND that the application's plugin API exposes, but the problem is that I'm not notified when the host application changes its own title text, so its changes overwrite mine. Can I use this HWND to somehow detect these title text changes? Edit: some code to get you started C# code:
Sedro fucked around with this message at 00:00 on Aug 25, 2015 |
# ? Aug 24, 2015 23:53 |
|
That's exactly what I'm looking for, thanks! edit: Well, apparently that actually only works for windows originally created using WPF, and this application is WinForms. However, it got me on the right track. edit edit: I'm having more trouble with this. Apparently the way I want to do things is with Application.AddMessageFilter, but no messages are actually being caught at any point. raminasi fucked around with this message at 01:04 on Aug 25, 2015 |
# ? Aug 25, 2015 00:02 |
|
Does anybody know if it is possible to send WinRT files to a different application? I want to do file exhange between a WinRT app and a regular .Net application, does anyone know any pointers for this without going the route of TCP sockets. Mr Shiny Pants fucked around with this message at 10:58 on Aug 25, 2015 |
# ? Aug 25, 2015 10:54 |
|
GrumpyDoctor posted:That's exactly what I'm looking for, thanks!
|
# ? Aug 25, 2015 16:38 |
|
Sedro posted:I thought this kind of thing would be easy by now. You will need to use P/invoke. Here's a code sample http://stackoverflow.com/a/9680911/3235823 (you will need to pass in your HWND to the SetWinEventHook call). Ok, I got this working, but only in WINEVENT_OUTOFCONTEXT mode (trying to pass an HMODULE that I got from Type.Module into SetWinEventHook results in a "could not find specified module" error). I assume by "pass in your HWND" you meant using GetWindowThreadProcessId to get the correct process and thread ids from the HWND? Also, I get eight events for every title change, but whatever.
|
# ? Aug 25, 2015 21:57 |
|
Mr Shiny Pants posted:Am I missing anything, or are you reinventing JSON? You're missing something. What I wrote there is a Dictionary<string, string> that is holding key/value pairs, which will eventually get stored in the database with the keys in one column and the values in the other. Nothing to do with JSON or serialisation at all.
|
# ? Aug 26, 2015 01:00 |
|
The Wizard of Poz posted:You're missing something. Serializing stuff into a dictionary isn't really that different than serializing it into some text format though.
|
# ? Aug 26, 2015 01:39 |
|
RICHUNCLEPENNYBAGS posted:Serializing stuff into a dictionary isn't really that different than serializing it into some text format though. It's a complete waste of time. Why would I take a model, convert it to key/value pairs, then convert it to JSON, then convert it back to key value pairs, so I can save it?
|
# ? Aug 26, 2015 03:13 |
|
Why am I getting code:
|
# ? Aug 26, 2015 04:14 |
|
The Wizard of Poz posted:It's a complete waste of time. Why would I take a model, convert it to key/value pairs, then convert it to JSON, then convert it back to key value pairs, so I can save it? don't do the first step. it's trivial to convert a model into json due to existing libraries, and from there converting to kvps requires very little work and no modification of the model types.
|
# ? Aug 26, 2015 05:39 |
|
The Wizard of Poz posted:You're missing something. Well, when I saw you converting the object properties to KVPs the first thing that came to mind was the Javascript Object Literal Notation, which are Key Value Pairs. So you could serialize with JSON.net to text and use LINQ to populate your Dictionary. Seemed like a good fit. code:
|
# ? Aug 26, 2015 07:12 |
|
Ciaphas posted:This isn't making sense to me, I'm not creating any views in code at all. My project has MainWindow.xaml as the startup in app.config, and that contains a tab control containing other views (backed by VMs created in code), but I'm not specifically constructing any views in C#. Quoting myself because I'm back at work after a long weekend and didn't really see a response. I'm also trying to google what IoC is (still assuming it stands for Inversion of Control) but failing to get it
|
# ? Aug 26, 2015 18:35 |
|
In a nutshell, it's really just the removal of creating objects within sections of code to remove that dependency to a specific object type. It adds complexity but not an incredible amount. It also keeps code better organized IMO. When used in tandem with Dependency Injection you basically never "create" an object in your classes (e.g. ViewModel). You instead pass everything you need in via a parameter in a constructor (usually as an Interface). That way you can easily swap out mock types, new variations of classes, etc... Ultimately you end up with a complex central hub that controls what objects are passed in to other classes such as with a Service Locator or Builder. A simple example would be instead of Directly calling a DataBase context from within your ViewModel you would instead have an Interface that outlined all the methods you need (Save, New, etc..) and that Interface would be passed in through the constructor. The DataBase context would actually be called by a Service class that implements that Interface which was passed in automatically by a Service Locator. You could them swap out different services - say for different DataBase contexts or even a mocked Service for testing. For more: https://msdn.microsoft.com/en-us/library/ff921087.aspx
|
# ? Aug 26, 2015 19:02 |
|
crashdome posted:In a nutshell, it's really just the removal of creating objects within sections of code to remove that dependency to a specific object type. It adds complexity but not an incredible amount. It also keeps code better organized IMO. I don't know how I feel about IOC and DI yet. I can see the improvements but I can also see the complexity they add. More and more I am coming around to the not having "magic" in my code like IOC, service locators and Aspect Programming. I thought this was a good presentation about keeping things simple: http://www.infoq.com/presentations/8-lines-code-refactoring
|
# ? Aug 26, 2015 19:23 |
|
Mr Shiny Pants posted:I don't know how I feel about IOC and DI yet. I can see the improvements but I can also see the complexity they add. There's minimal complexity added by using IOC. It's when people go nuts with IOC containers that the complexity arises. If you get to a point where doing DI is adding so much pain to your process that you feel like you really need an IOC container, you've just discovered a design problem. Code can be loosely coupled and still be an awful spaghetti mess. Like: I have a Frobulator class that needs to take an IFoo, IBar, and IBaz. IBaz needs to take an IButts and an IDongs IDongs needs an IWang and an IBar This means that you still have a spaghetti design and things need to be isolated more clearly.
|
# ? Aug 26, 2015 19:43 |
|
Like all patterns, it can be done very wrong. If you end up with constructors that have 10-12 parameters you are probably doing something wrong. The opposite is having too few parameters and ballooning service classes. It just takes practice and a little common sense. I use SimpleIoC paired with MVVMLight and so far my smallish applications have become slimmer as I learn to wrap my head around what is good for the developer and what will end up as spaghetti. I generally have a single ServiceLocator, a WPFWindowManager for calling pop-up Views, and a GlobalServices class (for basic things like access control/Identity). I also have a general EditorService which handles common routines like Saving, Editing, Deleting. In the end, I use maybe 3-5 service Interfaces per ViewModel and the majority of them are reused. It certainly adds more development time building it up but, coming back to a ViewModels/Views to alter logic almost never happens for me. I spend about 99% of my time focused on specific services when I want to tweak or alter Biz Logic. Tweaking Views or adding new functionality also becomes more trivial because I might only add a line or two of code to call the appropriate service method. I generally like programming this way because I hate UI programming and the sand pit it draws you into the moment you start coupling your business logic to them.
|
# ? Aug 26, 2015 20:21 |
|
This basically captures my point of view on DI. It's a good thing and a very simple thing. http://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html I feel pretty similarly about "inversion of control." Frankly it feels to me like OO programmers discovered modularity and just had to come up with a special term for it. I think inversion of control is a categorically poor term because it only has meaning in the context of "the way we used to do things." edit: It's also possible I have no idea what the gently caress I'm talking about. brap fucked around with this message at 21:24 on Aug 26, 2015 |
# ? Aug 26, 2015 20:29 |
|
Is having a ViewModel use a DbContext(as crashdome mentioned) an MVVM thing? It's not something I'd usually do in an MVC project. Should I?
chippy fucked around with this message at 23:07 on Aug 26, 2015 |
# ? Aug 26, 2015 22:56 |
|
fleshweasel posted:This basically captures my point of view on DI. It's a good thing and a very simple thing. Oh. Well, arseholes to that, I was already doing that. Why do people have to make things such that I don't even recognize I already understand them
|
# ? Aug 26, 2015 23:44 |
|
The Wizard of Poz posted:It's a complete waste of time. Why would I take a model, convert it to key/value pairs, then convert it to JSON, then convert it back to key value pairs, so I can save it? I thought I had some idea what you were trying to do but frankly I don't seem to understand. crashdome posted:When used in tandem with Dependency Injection you basically never "create" an object in your classes (e.g. ViewModel). Well I dunno about all you guys but in spite of using IoC I'm not going around passing in view models as dependencies. I think DI containers are great, despite others' objections here. RICHUNCLEPENNYBAGS fucked around with this message at 02:05 on Aug 27, 2015 |
# ? Aug 27, 2015 02:03 |
|
I think the JSON recommendations are stemming from a misunderstanding: the KEYS in my key/value pairs are arbitrary - they don't match the property names, and there's no algorithm I can use to transform a property name into the correct key for that property. So I need to have some kind of a lookup that I can use to lookup the correct key for a particular property. JSON wouldn't help because I would still need to generate my own keys, in which case there's no benefit in converting to JSON because the object I would be converting to JSON would already be the object that I'm after (a dictionary of string, string).
|
# ? Aug 27, 2015 03:23 |
|
What property names? You haven't mentioned any object that has properties on it. Is your dictionary supposed to get converted to or interpreted by an object that has some properties in it?
|
# ? Aug 27, 2015 03:35 |
|
the problem with MVVM is that it's incomplete. it specifies the viewmodel-view decoupled binding process, which is cool, but it doesn't give any indication of where your business logic or service access should live- there's just a vague 'models' layer which doesn't really make sense as you'd rarely want ui sections (v/vm) corresponding 1:1 to data types (m) there are plenty of possible architectures within that vagueness. some people have "fat" viewmodels containing logic and DB access; some connect viewmodels and services with a message bus. probably there's even someone who uses xaml "pages" and a top-down architecture where views construct viewmodels construct views using the .DataContext property, but I've never seen it done outside of sample code. personally I favour having 'controller' classes which work more or less like 'controllers' in a web application; controllers acquire data from wherever you put it, respond to ui actions (generally via ICommand) and create/modify hierarchies of viewmodels to present the result. i also use data templating so that viewmodels are almost exclusively 1:1 with views - in theory the capability of m:n VMs is very powerful but there doesn't seem to be an actual use case for it if you're doing this kind of bottom-up control. if you want to create and connect the controllers using an ioc container, well, go hog wild. frankly I can never remember which direction is or isn't "inverted" so I just put dependencies in constructors and assign them to private readonly fields.
|
# ? Aug 27, 2015 03:36 |
|
here, have a proslyetic diagram. internally we just call the viewmodels 'models', hence the scare-quoted M.
|
# ? Aug 27, 2015 03:41 |
|
The Wizard of Poz posted:I think the JSON recommendations are stemming from a misunderstanding: the KEYS in my key/value pairs are arbitrary - they don't match the property names, and there's no algorithm I can use to transform a property name into the correct key for that property. So I need to have some kind of a lookup that I can use to lookup the correct key for a particular property. I'm still like 90% sure the answer to your problem is to reflect over the properties of objects. You can maintain the mappings by either using an attribute on the properties (or just the ones that don't follow some predictable pattern) or just keep them in a dictionary or something. edit: Drur the chart has nothing to do with the serialization thing which is why I didn't understand the relationship at all. Sorry, folks. RICHUNCLEPENNYBAGS fucked around with this message at 03:52 on Aug 27, 2015 |
# ? Aug 27, 2015 03:45 |
|
RICHUNCLEPENNYBAGS posted:I'm still like 90% sure the answer to your problem is to reflect over the properties of objects. You can maintain the mappings by either using an attribute on the properties (or just the ones that don't follow some predictable pattern) or just keep them in a dictionary or something. I think you're right, and I'm leaning toward using an attribute to decorate the properties with the required string to be used for the key. fleshweasel posted:What property names? You haven't mentioned any object that has properties on it. Is your dictionary supposed to get converted to or interpreted by an object that has some properties in it? I can only suggest you check out my recent post history in this thread, I've explained the problem in quite a lot of detail.
|
# ? Aug 27, 2015 03:55 |
|
Ok, I found your post from last week. I think people are just so thrown by your database schema that they can't believe there's a problem here. I suggest you come up with a function for each model that consumes the dictionary, applies a set of keys to the dictionary and knows the conversion to apply on each value. Take your common stuff like address fields and just come up with functions that turn strings into addresses and addresses into strings for when it's time to convert back. Then call those functions as needed for each property. I don't think making every property on every model implement a certain interface will meaningfully reduce the amount of boilerplate involved in this. StringKeyValuePairable, NumberKeyValuePairable... then providing parameters in the constructor so they all know what database keys they use, it's still a lot of code to churn out.
|
# ? Aug 27, 2015 04:26 |
|
The Wizard of Poz posted:I think you're right, and I'm leaning toward using an attribute to decorate the properties with the required string to be used for the key. So it is a mapper? Depending on the DB, that could be a lot of work Working with an AS/400 by any chance? We have some awesome table and field names......
|
# ? Aug 27, 2015 05:29 |
|
Mr Shiny Pants posted:So it is a mapper? Depending on the DB, that could be a lot of work Working with an AS/400 by any chance? We have some awesome table and field names......
|
# ? Aug 27, 2015 05:40 |
|
Mr Shiny Pants posted:So it is a mapper? Depending on the DB, that could be a lot of work Working with an AS/400 by any chance? We have some awesome table and field names...... The software that owns the database this is to interact with is a ~20 year old beast that was never really built to any kind of sensible standard. I know people are reading my posts and thinking I'm stupid, but I didn't come up with this stuff, I promise. We're trying to take that database and build a middle level logic layer that we can then consume in a wide range of applications to handle the data in various ways. Unfortunately with such a long history it's not really possible to just throw everything out and start again, we deal with government reporting and so on so our customers are pretty unforgiving with big changes.
|
# ? Aug 27, 2015 07:49 |
|
The Wizard of Poz posted:The software that owns the database this is to interact with is a ~20 year old beast that was never really built to any kind of sensible standard. I know people are reading my posts and thinking I'm stupid, but I didn't come up with this stuff, I promise. I was just curious, and try not to judge.I think we all have stories that start with: "Because of reasons....."
|
# ? Aug 27, 2015 09:48 |
|
Gul Banana posted:the problem with MVVM is that it's incomplete. it specifies the viewmodel-view decoupled binding process, which is cool, but it doesn't give any indication of where your business logic or service access should live- there's just a vague 'models' layer which doesn't really make sense as you'd rarely want ui sections (v/vm) corresponding 1:1 to data types (m) There's nothing to suggest that the ViewModel and Model are 1-to-1. In fact I think a major reasoning behind the MVVM is to allow that separation; a ViewModel may use many Models and a Model may belong to many ViewModels. The model itself is vague whatever gets the job done stuff in this context, but it's a separate concern TheBlackVegetable fucked around with this message at 13:42 on Aug 27, 2015 |
# ? Aug 27, 2015 12:31 |
|
|
# ? Jun 7, 2024 09:01 |
|
TheBlackVegetable posted:There's nothing to suggest that the ViewModel and Model are 1-to-1. In fact I think a major reasoning behind the MVVM is to allow that separation; a ViewModel may use many Models and a Model may belong to many ViewModels. Yes. Personally, my Model is in a different "Core" assembly (Class Library project). My ASP/WPF/WinForms/Console "UI" project references Core, as does my Test project. The Core is "The Real Application", and when I'm writing any code in Core, I often ask myself "can I sensibly poke this code with a Console project, and an ASP project, and a Test project?" and if not, I'm probably doing something wrong.
|
# ? Aug 27, 2015 15:22 |