|
Quote: CBS All No Access
FTFY - As luck would have it, no-one is upset about this.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I read the subject line as referring to the Discovery Channel. Well, nope...
|
|
|
|
|
Against many whales, the short Spanish down under. (9)
This space for rent
modified 24-Sep-18 4:28am.
|
|
|
|
|
Against ANTI
many whales, POD
the short Spanish ES
down under.
ANTIPODES
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
We have a winner.
This space for rent
|
|
|
|
|
Hi all!
I think I need some help in navigating the incredibly huge sea of web technologies that have appeared in the last years - it has been a while since I had the time to actually study newish frameworks and products.
My job consists mostly of LoB applications, so until now I have found myself very comfortable with ASP.net Web Forms, WCF for AJAX interactions, a little bit of jQuery and ADO.net for database access - trying to keep it simple on the client side and have most of the work done on the server side. To achieve a 'modern' look I use the DevExpress Web Forms controls, and that's pretty much it.
It feels, however, like I'm missing something. Everybody is talking about different approaches but they all seem like huge steps backwards to me. I can't honestly believe people are more productive this way.
- ASP.net MVC? Yeah, just put some server side code alongside HTML. Back in my days we called that Classic ASP, and we hated it. Bonus hell points: video tutorials.
- Data binding? Yeah, bind everything to a EF context, you get IQueryables, it's fast! Oh, you need to call an API? Tough luck... no data binding for you. Back to ObjectDataSources!
- Bah! HTML5 and JS is all you need! Just use server side code for your APIs and learn to love
Angular/KnockoutJS/SoupOfTheDay and AJAX calls! Yep, until the devil finds you in the 666th level of callback nesting. Oh, and no strict typing for you - I swear, you don't need it. Except when you need it, and it's in production, and you got screwed by something that in server side code would have never happened. More bonus hell points: huge javascript files with very little editor support.
There MUST be some secret that all of the fancy web dev are hiding from me. Like, you know, a C# client side variant that gets compiled to JavaScript, has some DOM manipulation helpers and lets us avoid all of this mess. Bonus points if the examples' code works, because most of the other technologies' tutorial are either 'a) Dumbed down beyond the point of usefulness' or 'b) Outdated and just plain not working without the exact balance of dependencies and API keys and the right moon phase'. Is there a single tutorial that builds a real LoB application? I swear, I only need authentication, authorization, some attention to security and invoking web services. And some UI like forms, popup dialogs and toolbars.
This is becoming a rant and I didn't really want that. I really think this is my fault. I just don't know where to start - and be productive with a simple but complete web app. I like having web services for application logic. I am ready to ditch Web Forms. I just don't want to lose my time again and again. Do you have any suggestion?
Thanks in advance
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
I was hoping to help you and started reading your post.
Unfortunately about two lines into your post, my something in my head went BAZZZINGA!! and it was all downhill from there (hint: I'm of no use to you).
When I read this line, there was a conversation of this sort in my head:
Luca Leonardo Scorcia wrote: My job consists mostly of LoB applications
Mind: There are LoB applications, Rajesh.  
Me: Yeah?
Mind: LoB applications, there are; you stupid twonk. Also, your mouth is open, Rajesh. Close it.
Me: Mate, th...
Mind: STOP IT! This from a guy who thinks his knowledge is out of date. And you don't even know what's an LoB application. When are you going to ask for help?
Me: Hmm?!
Mind: When are you going to build an LoB application?!
Me: [Grabs the sandwich from the side table]
Mind: Yeah, that's right. Keep eating. Would you like fries with that samich, capt'n fatso?
Mind: I bet LoB is different than IoT. Your RPI-connected-IoT-enabled fruit peeler project wasn't all that good.
Me: I know.
Mind: Learn how to do an LoB application.
Me: But the dude says something along the lines of his skills being already out of date, yes?
Mind: Oh!
Me:
Me: [takes an enormous bite]
Mind: God, that's dry. Samich needs more sauce.
Me: OK, will do.
|
|
|
|
|
|
I'll try and start from the top....
What's "LoB"?
|
|
|
|
|
LOB applications are usually large programs that contain a number of integrated capabilities and tie into databases and database management systems. Had to google it 
We use the term LOB as well but it describes a market segment.
|
|
|
|
|
|
I feel your pain, Luca. I've been writing LoB applications for most of my career (thankfully!), most of the time with small companies and operating as a freelancer. At the end of the day, the client neither knows nor cares what technologies you've used; until, that is, the day you're not around and he needs to find someone to enhance the application that's powered his business for the past 15 years. At that point he'll be less than pleased - and his estimation of you will plummet - when he finds you're using some flavour-of-the-month framework that went out of fashion 10 years ago and no-one will touch with a barge-pole.
I've found that keeping it simple - ASP.Net (either C# or, yes, VB.Net which saves a serious amount of faffing about) with WebForms, ADO.Net, JQuery and some simple ASMX webservices does everything I've ever needed to do. Conversely when working with "99% complete" applications that I've been asked to "finish off", I find an enormous pile of redundant code, a massive dependency list and at least 2 or 3 versions of frameworks and tools that are no longer supported or even accessible.
It sounds like you're pretty much in charge technically; so stick with what you know and works, and build up your own personal library of routines and techniques for the things all these applications need to do. Even with a restricted toolset, you'll find you still learn new stuff about it every week, you still learn new ways to use it, and still get that satisfaction from solving problems elegantly and robustly.
Have fun!
PS LoB = Line of Business - those un-sexy, day-to-day back office applications that keep businesses running day in, day out.
|
|
|
|
|
Even now you'll probably struggle to find people who do webforms, or want to do them anyway.
|
|
|
|
|
You're right there (had to try and find a competent WebForms developer to take on a project I didn't have time for (would have used lots of common code from an existing WebForms application I'd written) and simply couldn't find anybody. Which I think is a great shame as WebForms is a mature, proven and highly capable platform with a huge codebase to borrow from. Done properly it can be very efficient and, as above, I've never found anything I can't do with it.
I looked at MVC and took the conscious decision not to learn / use it. But that's because I'm now semi-retired and really just maintaining existing customers; for career protection if I'd been even 10 years younger I think I'd inevitably have gone down that road.
|
|
|
|
|
I'm a competent WebForms developer. Just sayin'...
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
When I started to seriously write web apps, both for personal use and for my clients, I came up with three "truths":
TL;DR:
- It's got to look good and be fast.
- It's got to be clean code on the client.
- It's got to be clean code on the server.
Elaboration:
- The user doesn't care what's behind what they see, they want a fast and good looking UI. For that reason, I glommed onto jqWidgets (lovely controls, but there is a minor performance hit because jqWidgets doesn't support minified .js files, mitigated by turning on compression. I also use Bootstrap because it works very nicely for helping me style the UI on mobile devices. And that's it. I also code the client-side almost always as a responsive UI -- auto-update the server on a UI change, and I use HTML5's websockets for auto-syncing the client.
- I do care what is behind what the user sees, so after fussing with a couple of them, I ditched all those SoupOfTheDay frameworks. Really don't need them. I learned enough of the DOM and Javascript (with frequent googling to learn what the best--by my judgement--way to do something is) and learned how to write cleanly structured and maintainable Javascript -- the rule is, write very small functions. I look at patterns in my code and refactor them into reusable functions. Rinse and repeat.
- I also care what's on the server side. That means C#, my own web server which can run standalone or under IIS (which is nice for hosting multiple HTTPS sites), using LetsEncrypt for certs and a acme.net for cert renewal. It's in C#, I don't use EntityFramework, preferring my own as powerful but much more lightweight implementation relying on just Linq2Sql. Most importantly, everything on the back-end that the client has to talk to (or listen to) is handled by a clean API architecture.
Now, you don't have to go down the whole "re-invent the wheel" process that I went down, and it was a major decision to throw out those client-side frameworks as well as EF, as well as the Microsoft web server stack and selectively roll my own. Not very marketable on my resume, haha. But I get a very clean separation of concerns and what I consider to be very maintainable web apps. And nothing uses Nuget. 
So, at the end of the day, I need to know:
jqWidgets
Bootstrap
Javascript
DOM
C# /.NET
SQL
JSON
That's it.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
We use Angular (4+) as the front end stack and today I'm busy trying to update it to v6... unsuccessfully so far  And then there are all the npm packages to update as well. A bit of dll hell in a way. So I definitely see your case for not using all these fancy frameworks.
|
|
|
|
|
Interesting answer.
I'm working on an enterprise solution built using WebFroms, and I'm worried about not being able to keep up with the market requirements since every day a new JS framework comes out and you know, Telerik and ASPX with very little JS is not a very mainstream solution.
The interface and it's connected to many class libraries, each containing its own business logic and data access layer, respectively.
I'm interested in the possibility of separating the class libraries from the interface with a microservice architecture by providing data in JSON through APIs, would you recommend it?
|
|
|
|
|
My answer will make me sound like a Microsoft FanBoy but I will go ahead and offer it and attempt to back it up.
Learn ASP.NET Core (.NET Core).
Here's why.
1. Visual Studio Community is (basically and almost entirely) free.
2. The .NET Core includes everything you need to create true Enterprise Apps
a.) VSTudio dev environment - wraps up build, minifying JS,
b.) There's an entire plan for developing web apps but it is still open.
c.) You can build ReactJS or AngularJS later on top of your ASP.NET MVC site anyways (if you decide to go that way later
d.) Microsoft wraps up the basics you will most certainly use : C# (for backend), HTML created via generator (Razor), Asynchronous support (AJAX but better), jQuery is there, Bootstrap is there
e.) It is very modular -- only add what you need for your web app (everything is added via Dependency Injection of services)
f.) You get the package management (Nuget) to add custom things you need.
It's all wrapped up nicely and will get you there with solid patterns.
To get more detail read Dino Esposito's book, Programming ASP.NET Core, Programming ASP.NET Core[^]
or start with my intro article here on CP which will provide an intro and overview of more details why I think Microsoft is going to win in this area:
ASP.NET Core : Building Enterprise Solutions (Intro & Chpt 1 of N)[^]
|
|
|
|
|
Luca Leonardo Scorcia wrote: I am ready to ditch Web Forms
So what's the problem with Web Forms? If they get the job done, use them. I'm helping a colleague who has been 'out of the game' to get started with a Web Forms LoB application.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I have been working on an architectural reference application for that, having developed server code for a web API in C# and PHP, and client code in Angular (keep looking wistfully at Vu), Android and iOS. The web API is the linchpin of it all. The web API has EF in the backend, and I have even been trying to get it to work with ADFS. I wish I could put it out there, but my boss won't let me. On the other hand, I now value the simplicity of HTML forms created on the server and presented to the client. And I keep thinking how much of a shame it is that the DOM couldn't be rewritten from scratch to be easier for programs to work with and JavaScript didn't mess up the scope of variables declared in function calls. And it really bugs me that some sales person renamed LiveScript to JavaScript to be trendy, just confusing everybody.
|
|
|
|
|
Doesn't matter what you learn: the "employer" will always require at least one more obscure tech skill that you don't have.
Eventually, you will stumble into something you haven't dealt with before and that will require you to learn a completely new skill set in a week (because saying you don't know how to do something is lame).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
|
Luca...
I ran into the same issues that you experienced with ASP.NET MVC. IN 2010 I worked on one of the largest MVC projects in the United States at the time.
Though we accomplished a lot, the project was canceled due to massive management issues between the client's management and my own firm's own management.
However, the decision to use ASP.NET MVC played a major factor in this cancellation due to the fact that there was little way to accommodate large requirement changes to the interface.
As a result, after I left this assignment I gave up working with MVC and stuck with WebForms for the rest of my years in corporate positions and consulting contracts. And now that I am retired and working on my own development projects, I still won't consider relearning MVC for web development.
To begin with, there is nothing new or radical about the MVC paradigm. It was actually designed back in the 1970s.
ASP.NET already had a complete implementation for MVC with the Castle Project's, Monorail Environment. It was Open Source and completely free to implement with full documentation but it didn't seem to register with the larger technical community.
When Microsoft introduced their own version of ASP.NET MVC it was a complete mirror image of the Castle Project's implementation. I always wondered if they had made some type of deal with the people at the Castle Project.
In any event, many developers claim that ASP.NET MVC provides better performance and a superior separation of concerns among other positives. However, this is all complete nonsense since the negative aspects of MVC detract so much from its benefits as to neutralize them completely.
ASP.NET MVC is much harder to learn than WebForms and the complexities involved make it a much more difficult environment to work with, since so much is based upon JavaScript. This last makes debugging a much more difficult endeavor.
If you design a WebForms application properly and use the recommended hardware and application server recommendations that have been developed over the years, ASP.NET WebForms can be blistering fast. And in some benchmarks has equaled or exceed the capabilities of its MVC sibling. And the bigger the MVC application, the larger the routing requirements, which have always been a large bottleneck for MVC since it has historically relied on Reflection (unless that has been changed in the most recent version upgrade).
The problem with WebForms is the same with most technologies; people make a mess out of their implementations and then blame the environment for the issues. This has been particularly attribute to many developers loading up Code-Behind modules with everything but the kitchen sink when in fact this module was only supposed to act as a dispatcher for other tiers. However, what happened here was that many organizations didn't support actual tiered development and threw everything onto an IIS application server even when the assemblies were supposed to act as separate tiers.
The benefit of having multiple, physical tiers was proven in the 1990s but no one was paying any attention.
ASP.NET MVC then took off because many developers, especially the newer ones to our profession, were under the misguided perception that it would cure the WebForms bloat, much of that being the fault of the developers themselves with quite a bit of help from the hardware people who wouldn't support physical tiers.
To add injury to insult, new paradigms came to the fore (ie: DevOps), which relied on the so called faster developments of MVC under the Agile paradigm. As a result, what you have now is the equivalent of a software version of the US Air Force's F-35 fighter; a development environment that was premised on an existing concept that was never designed for large scale development. In the case of the F-35, the US Marines insisted on the basis of a flawed air-frame design that had already been proven to be unfeasible for multi-role purposes (ie: the Marines Super Harrier, which was designed for immediate ground support and light interceptor work based off of the British Harrier design. This latter design was fought to a standstill by the Argentinian Air Force during the Falklands War in the 1980s.).
This all being said, there is an indication that Microsoft may be working to return to its WebForms roots with the introduction of Blazor, which allows you to use C# on the front-end. Now the questions comes up, what do you do with all those JavaScript frameworks and components since if they are still to be used alongside C# one would then have to support three languages on such web development; HTML, C#, and JavaScript.
I suggest that Microsoft is looking for a compromise between the MVC and WebForms paradigms, considering that a whole new slew of components will have to be designed to take advantage of Blazor. And will this mean an option to return to the use of server-side controls?
Here is a link to a new essay on the same subject but in broader terms... http://tonsky.me/blog/disenchantment/
27.09.2018
And here it comes from Microsoft; a possible return to a very new WebForms...
"Microsoft is also working to implement Razor Components, or server-side Blazor, in version 3.0, which integrates Blazor into ASP.NET Core and allows it to run on the server with .NET Core. This can greatly help the compatibility of web apps, as the same code can run on many of different devices using WebAssembly, without any code changes required. .NET Core 3.0 doesn't have a set release date yet, but it will be available in public preview later this year."
Taken from the following recent article...
https://www.neowin.net/news/heres-whats-new-and-coming-to-net-core-with-versions-21-22-and-30/
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
modified 27-Sep-18 9:52am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
