|
mastersord posted:I apologize in advance for sounding like an inexperienced moron. I am in the process of trying to upgrade all our in-house code from VB6 to VB.NET and since we're so small, no one really knows anything about visual Studio past VS99 or whatever was the last VB6 release. I am trying to catch up on the last 10-15 years of advances on my own. Welcome to present day. Here's what you're going to learn: VB.NET is not even remotely close to VB6 Your going to have to completely rewrite everything. Your concept of programming is antiquated and everyone hates it and if you continue to rewrite your software using old methods, young developers will never want to maintain your software. I'm not trying to be snarky or cruel but, as a person hired to update VB6 programs to present day technology, it is going to take your VB6 devs well over a year to come to grips with everything new. You'll be far more comfortable and it will be far more cost effective if you hired up-to-date developers and just let them build what you need for you. Internet != HIPAA violation Web technology is far more flexible. Personally I build and prefer standard applications (now WPF) but even I have to embrace there's always going to be overlap between Web and Native applications.
|
#
?
Jan 12, 2015 02:28
|
|
|
|
| # ? May 23, 2024 23:28 |
|
|
mastersord posted:I apologize in advance for sounding like an inexperienced moron. I am in the process of trying to upgrade all our in-house code from VB6 to VB.NET and since we're so small, no one really knows anything about visual Studio past VS99 or whatever was the last VB6 release. I am trying to catch up on the last 10-15 years of advances on my own. The differences between VB6 and VB.NET are completely orthogonal to whether you want a web app or not. Does your current application serve web pages? Then MVC will help you do that. If not, then don't even worry about it. And I've never used VB6 myself, but everything I've heard about it describes it as essentially a completely different language from VB.NET. VB6->VB.NET isn't an "upgrade," it's a complete rewrite.
|
|
#
?
Jan 12, 2015 02:31
|
|
|
mastersord posted:Why does it seem like everyone is making web apps as opposed to local apps? In my shop we have no need for any special internet applications outside of the browser and with HIPAA we have little to no reason to unnecessarily expose our data to the internet more than required.
|
|
#
?
Jan 12, 2015 03:27
|
|
|
In addition to everyone else's excellent points, the draw of web apps these days is multi-platform support. People don't just have desktop PCs anymore -- they have phones and tablets as well. Writing your desktop application so it runs natively on every platform is (probably) more difficult than writing a web application. Of course, web apps have a whole different nightmare of browser compatibility issues, but it's probably easier to fix those issues than ensure that your desktop application can run on Windows (XP? 7? 8? 10?), OSX, iPhones/iPads, Android phones, Windows phones, and so on. If your organization is standardized on one OS and the rest don't matter, and you don't think anyone will ever need or want to use your application from a phone or tablet, then yeah, by all means, keep it as a desktop application.
|
|
#
?
Jan 12, 2015 03:36
|
|
|
mastersord posted:I apologize in advance for sounding like an inexperienced moron. I am in the process of trying to upgrade all our in-house code from VB6 to VB.NET and since we're so small, no one really knows anything about visual Studio past VS99 or whatever was the last VB6 release. I am trying to catch up on the last 10-15 years of advances on my own. It's cross-platform, you're less likely to build some software incompatible with the new version of Windows keeping you from upgrading or whatever, and deployment is easy. You don't have to use this stuff over the Internet if you don't need to. Advances both in JS interpreters and in JS libraries also make it a lot more plausible to do things in the browser that used to be pretty difficult. That said, working with MVC will be an even bigger shift in thinking than jumping into .NET. A lot of Web stuff written by mostly-desktop guys ends up being pretty rough. Ithaqua posted:Of course, web apps have a whole different nightmare of browser compatibility issues, but it's probably easier to fix those issues than ensure that your desktop application can run on Windows (XP? 7? 8? 10?), OSX, iPhones/iPads, Android phones, Windows phones, and so on. RICHUNCLEPENNYBAGS fucked around with this message at 04:50 on Jan 12, 2015 |
|
#
?
Jan 12, 2015 04:45
|
|
|
When you're responsible your writing and deploying applications, managing one internal IIS server become much better than dealing with desktops.
|
|
#
?
Jan 12, 2015 05:34
|
|
|
First off, thank you for all your responses! From my experiences so far, i know vb.net and vb6 are different. The differences are more prevalent in how form controls work and also going from ADODB to ADO.NET.
|
|
#
?
Jan 12, 2015 06:04
|
|
|
I'd suggest that if you're looking at a desktop application in vb.net you shy away from using winforms and learn to properly use WPF if possible. As said before, you'll need to rewrite the majority of your code anyway, so I'd really suggest starting with the more modern approach using MVVM and WPF rather than a vb.net winforms application made to mimic a vb6 application. A few pitfalls aside(The Datagrid and Browser controls have been really annoying to work with in my opinion), WPF seems like such an improvement after spending few years with a vb.net winforms app built off a vb6 forms app. Not that it's impossible to make a good winforms application, I'd just say it might be worth the effort to use the more modern approach. Calidus posted:When you're responsible your writing and deploying applications, managing one internal IIS server become much better than dealing with desktops. Oddly enough, this has been a fairly easy for me to handle using a ClickOnce deployment with a publish directory on a shared drive. ClickOnce seems to suck at a lot of things, but internal deployments have been really easy using it. wilderthanmild fucked around with this message at 19:19 on Jan 12, 2015 |
|
#
?
Jan 12, 2015 19:09
|
|
|
Yeah VB6 more logically progresses to WPF/WinForms unfortunately, in that you're still dealing with relatively familiar form elements, events, triggers, etc. That said, making a WPF app in this day and age still feels a bit weird, but it might work out for you. I actually went from VB6 -> ASP Classic -> ASP.NET -> VB.NET, but I was always more of a database logic guy than an interface guy so it was mostly a positive experience. I'm trying to remember what the biggest gotchas coming out of VB6 were, but they mostly relate to declaring variables and scope, not having to deal with ODBC for database (hallelujah!). Other than that IF THEN is still IF THEN, FOR NEXT is still FOR NEXT, etc. Oh and always use GOTO.
|
|
#
?
Jan 12, 2015 20:04
|
|
|
mastersord posted:The differences are more prevalent in how form controls work and also going from ADODB to ADO.NET. Just wait until you see LINQ and Lambda Expressions!
|
|
#
?
Jan 12, 2015 20:36
|
|
|
My biggest hurdle thus far has been going from ADODB to ADO.NET for database stuff. Mainly problems with direct SQL calls that should've been done as database objects (views, functions, stored procedures). For us the ADODB recordset did everything once you gave it a connection and a command. In ADO.NET, the recordset is split into several objects that have to be linked together (data adapter populates a data set which contains one or more data tables). I wrote a class to manage these relationships, after having problems with the interop libraries trying to support ADODB. I should be using stuff like Entity Framework, but the learning curve kinda scared us away.
|
|
#
?
Jan 12, 2015 23:45
|
|
|
Working on an EF project. I've only worked on one before, and it was set up so I could easily get to the designer, etc. Welp the one I'm on now is apparently not. I feel lost as poo poo and generally don't know how in VS2013 you do the magic with your data tools to set up your data contexts; I've only ever used the designer. What's a good place to poke around and make sure everything is up to date with db changes and such? Also it uses the UnitOfWork pattern and ninject.  What happened to just using ADO.NET and a folder of business objects? Imposter syndrome is coming on something fierce.
|
|
#
?
Jan 13, 2015 00:56
|
|
|
Space Whale posted:Working on an EF project. I've only worked on one before, and it was set up so I could easily get to the designer, etc. Welp the one I'm on now is apparently not. mastersord posted:My biggest hurdle thus far has been going from ADODB to ADO.NET for database stuff. Mainly problems with direct SQL calls that should've been done as database objects (views, functions, stored procedures). I was in exactly the same position as your guys two months ago ("DID ADO AND SQL STOP WORKING OR SOMETHING ?????!!!!") See pages 34/36 of this very thread. I got great advice there. You need learn a new thing, sorry. Go through the tutorials for EF, Hibernate and Dapper. Pick one and learn it. I highly recommend trying EF first using videos on Pluralsight.They're what made everything click for me. There is a steep learning curve but with 3 or 4 days dedicated study you can start being productive. Its been great for me,dev is so much quicker now that I'm using EF. I implemented a unit of work pattern as an exercise but I just couldn't see the benefit of it on top of EF. Theres another great video on Pluralsight called "Building a application framework in .net mvc" or something like that. and he use DI in a really practical way to keep the code clean, and to implement cross cutting concerns. Im not shilling for Pluralsight, I just found them very useful.
|
|
#
?
Jan 13, 2015 02:47
|
|
|
Space Whale posted:Working on an EF project. I've only worked on one before, and it was set up so I could easily get to the designer, etc. Welp the one I'm on now is apparently not. EF is unit of work!
|
|
#
?
Jan 13, 2015 05:13
|
|
|
I once wrapped my EF implementation inside a UnitOfWork/Repository abstraction because... ... Anyway, you don't need to do that. The DbContext already implements those patterns.
|
|
#
?
Jan 13, 2015 06:35
|
|
|
Sounds like a good plan and I will give it a shot. My team is very small (meaning my boss and myself). I mainly handle the coding aspects and he handles the database stuff but I'm pretty fluent in both (or at least i like to think so).
|
|
#
?
Jan 13, 2015 06:57
|
|
|
Wardende posted:I once wrapped my EF implementation inside a UnitOfWork/Repository abstraction because... ... Anyway, you don't need to do that. The DbContext already implements those patterns. The only reason to do it is testing, I think, but EF7 will have an in-memory provider for this exact scenario.
|
|
#
?
Jan 13, 2015 13:49
|
|
|
Thank goodness. I also once wrote a very complicated Moq framework of EF that was only about 70% effective, so I'm pleased to hear about this.
|
|
#
?
Jan 13, 2015 15:51
|
|
|
The thing for me is I've done data-first, and code-first is just "huh? What does the contexts? Where's the magic?" My architect is going to give me and other developers a proper walk-through today, so I'm happy with that. About UoW in your EF so you can work while you work: It's only used to call a .Commit() method in a POST verb. We're using all this magical poo poo in a webapi controller; every GET verb is just touching the repository for any given context. Is that sensible?
|
|
#
?
Jan 13, 2015 16:36
|
|
|
Can I use a wildcard to search for directories that start with a certain string? Pseudo-code example- If *DirExists*("C:\Program Files\ABC" & *Wildcard here* & ".txt") Then *Do something*
|
|
#
?
Jan 13, 2015 16:37
|
|
|
TheEffect posted:Can I use a wildcard to search for directories that start with a certain string? Pseudo-code example- Directory.EnumerateDirectories
|
|
#
?
Jan 13, 2015 16:53
|
|
|
Excellent, thank you!
|
|
#
?
Jan 13, 2015 16:56
|
|
|
Anyone with Lucene experience know how I can speed this up?C# code:Knyteguy fucked around with this message at 23:19 on Jan 13, 2015 |
|
#
?
Jan 13, 2015 23:15
|
|
|
Pull the QueryParser construction out of the loop? Also you can probably use MultiFieldQueryParser. Also consider whether you even need category IDs to be analyzed
|
|
#
?
Jan 13, 2015 23:29
|
|
|
Space Whale posted:The thing for me is I've done data-first, and code-first is just "huh? What does the contexts? Where's the magic?" My architect is going to give me and other developers a proper walk-through today, so I'm happy with that. I have used EF almost daily for like a year, so I feel like I should be able to help, but I don't really understand what you're saying.
|
|
#
?
Jan 14, 2015 01:52
|
|
|
RICHUNCLEPENNYBAGS posted:I have used EF almost daily for like a year, so I feel like I should be able to help, but I don't really understand what you're saying. I went from the use the designer, create an EDMX file, data-first EF world, to this babby snowflake (the crux of the problem) code-first mdoel which has custom UoW wrappers and hand written contexts AND uses automapper. I think my problem is learning multiple libraries and our convoluted architecture at the same time.
|
|
#
?
Jan 14, 2015 17:41
|
|
|
I'm writing my first web api, and each controller has only get, put, post etc methods, which seems like it's going to result in a large number of controllers over time, because there are quite a few types of object to interact with, and different systems interact with the same object in different ways. Is this the modern way to do things or am I missing the point? Actually, just typing this out made me think I should reduce the number of controllers and have overloads on the verb methods, but even so I feel like I'm doing something wrong.
|
|
#
?
Jan 14, 2015 19:57
|
|
|
Can you present some actual example or analogy of the controllers/objects/methods you envision creating? It is not really possible to advise on such a topic in the abstract.
|
|
#
?
Jan 14, 2015 22:05
|
|
|
Sedro posted:Pull the QueryParser construction out of the loop? Also you can probably use MultiFieldQueryParser. Also consider whether you even need category IDs to be analyzed Thanks. I made the changes mentioned. It turns out that this wasn't the bottleneck after all however. The lag time in running through the loop was just a problem specific to my development PC running out of processing power. The actual problem turned out to be that the base software we've built upon is terribly inefficient (which we've known for awhile), and it was a problem stemming from the core code. It was trying to pull 60,000 products from Lucene all at once and just eating up resources like crazy.
|
|
#
?
Jan 14, 2015 22:39
|
|
|
mortarr posted:I'm writing my first web api, and each controller has only get, put, post etc methods, which seems like it's going to result in a large number of controllers over time, because there are quite a few types of object to interact with, and different systems interact with the same object in different ways. Based on what you wrote, I think you're doing this: C# code:C# code:
|
|
#
?
Jan 14, 2015 22:43
|
|
|
mortarr posted:I'm writing my first web api, and each controller has only get, put, post etc methods, which seems like it's going to result in a large number of controllers over time, because there are quite a few types of object to interact with, and different systems interact with the same object in different ways. Looks like i was missing the point of rest/web api to some extent. I had controllers named around the action like DocumentRegistration, DocumentCount and DocumentList. Refactored around resource (following more research), so I have Document and Documents controllers, with count or list operations selected via config object now. Typing on my phone sucks, got no code examples sorry.
|
|
#
?
Jan 14, 2015 23:18
|
|
|
mortarr posted:I'm writing my first web api, and each controller has only get, put, post etc methods, which seems like it's going to result in a large number of controllers over time, because there are quite a few types of object to interact with, and different systems interact with the same object in different ways. Shouldn't you be writing stuff like this? code:
|
|
#
?
Jan 15, 2015 02:13
|
|
|
I have 2 buttons on a wpf window(play and pause). If I hit pause, then close the window, everything is fine. If I close the window while still playing, my program locks up indefinitely(a third party api call that never returns). In the Window.Closing event... code:code:
|
|
#
?
Jan 15, 2015 02:20
|
|
|
ljw1004 posted:Shouldn't you be writing stuff like this? Why wouldn't you just configure the routes properly instead of attributing each one? The default is to just use the controller name and HTTP verb but I hate that; I just configured it with MVC-style routing. Space Whale posted:I went from the use the designer, create an EDMX file, data-first EF world, to this babby snowflake (the crux of the problem) code-first mdoel which has custom UoW wrappers and hand written contexts AND uses automapper. I think my problem is learning multiple libraries and our convoluted architecture at the same time. I'm still not sure I understand, but the controller is instantiated, runs an action method, and is disposed with each request. You can work out how to do this, but you want an entity context to be spun up with each request and disposed at the end. I use a DI container to do this but you can add the context as an instance field and dispose it in the controller's dispose method or you can jsut use a using statement. RICHUNCLEPENNYBAGS fucked around with this message at 03:15 on Jan 15, 2015 |
|
#
?
Jan 15, 2015 03:13
|
|
|
I'll give an example: Our WebAPI controllers have in the constructor's parameters at least one IRepository<BizObjectType> foo and one IUnitOfWorkFacotry uowFactory. I guess the architect reallly, really likes UoW and hand written contexts? code:code:code:
|
|
#
?
Jan 15, 2015 19:29
|
|
|
.NET MVC 4.5 Entity framework (Web Api)code:When executing this code I look at Sql Profiler and see that that command issued is sp_executesql 'sqlstatement stuff'. is there a way to have it invoke the sproc directly? Question 2: Am I blind or are stored procedure output parameters wonky in Entity Framework?
|
|
#
?
Jan 15, 2015 19:57
|
|
|
I'm not a MVC/Entity expert at all, but I think that sp_executesql is being called because you're passing in a string and having it executed directly, and the server at run time has no idea if you've passed in a proc or a dynamic string. I have no exposure to the framework but I'd expect the sproc to only get explicitly called the server knows it directly. Again, never coded for it but I'd expect something like:code:
|
|
#
?
Jan 15, 2015 21:23
|
|
|
Please use attribute based routing and have your controllers use reasonable method names.
|
|
#
?
Jan 15, 2015 22:05
|
|
|
Space Whale posted:I'll give an example: Ok there's nothing inherently wrong with the UoW pattern or the repository pattern, but a lot of people, you included, have pointed out its a needless abstraction of EF. // this guy loving hates the repo patteren http://ayende.com/blog/search?q=respository // another https://cockneycoder.wordpress.com/2013/04/07/why-entity-framework-renders-the-repository-pattern-obsolete/ //another http://tech.pro/blog/1191/say-no-to-the-repository-pattern-in-your-dal // Unit Of work The anti UoW stuff is a little harder to find probably because its not so widely used in demos . A reason to implement UoW on top of EF is to abstract away the specific ORM, not incase you decide to change orm but for testing. Are you guys Test-First? That might be a reason for UoW. Why aren't' you asking the "architect" why you're using this stuff? You should have the confidence to say "I don't understand this, please explain this decision". Also I don't understand why you're annoyed by the "hand-written" dbcontext. Surely you've come across databases with schemas "hand-written" in SQL. Your main problem is new concept overload. Take your time and learn the fundamentals of the new tech.
|
|
#
?
Jan 15, 2015 23:13
|
|
|
|
| # ? May 23, 2024 23:28 |
|
|
Oh I did ask, and I'm learning. I value second opinions, and here I'm not asking someone I work with. Yes, we're doing unit tests as of right before I started, which is why it's still very new to the team. Thanks for the breakdown!
|
|
#
?
Jan 15, 2015 23:57
|
|