A question on architecture

[Miles]

Hello good people. New here. First post.

First up, I am by no means a "professional" developer. I have written quite a few desktop applications in Python Qt, VB.NET and C# WinForms, Java Swing (many years ago), and a whole bunch of code to automate host applications with VBA (Excel, Access, AutoCAD, Solidworks), but I have very limited experience creating browser based solutions. I write code as part of my job but it is not the entirety of my job. I am a self-taught developer.

So, I'm looking for some architectural advice for a solution I will be starting soon.

Basically, it is a job scheduling system for a small manufacturing environment. The current system we are using is a simple two-tier MS Access application built roughly 15 years ago that is constantly crashing. So, given that the system needs to be replaced we thought we would take the opportunity to add some new features to it, primarily, adding workstations around the workshop and using barcode scanners to log times.

One of the requirements is that it will need to be accessible from both Windows and Raspbian (if this is not feasible, then perhaps Windows IoT devices). It will also need to read data from an old IBM iSeries AS400 system, and a MySQL database I have running on a really old Windows Server. I also have another old Windows Server 2012 R2 machine available for IIS if required.

What I was orignally thinking was trying to get all the old data out of the Access database and putting it into a "proper" database like MSSQL or MySQL. Then creating three front-end interfaces for the following tasks :

• Administration of the system (adding new user accounts, modifying drop down fields in the front-end, system clean-up, perhaps getting access to the database in a less restrictive manner). This will be used by myself and the line managers.
• Entering new jobs into the system and getting the details on completed jobs. This will only be used by job co-ordinators and line managers. When a co-ordinator attempts to enter a new job into the schedule it will be validated against the AS400 data to ensure that a job exists and it will pull the data about that job from there and data about the item to be manufactured from the MySQL database. It will then go on to create a "Job Card" which is currently a physical printout of an Excel sheet that workers enter their names and times for different processes in the manufacturing of the item onto. It will also find the associated files for the job on a DFS and printing them all out (engineering drawings, test cards, inspection checklists, etc.)
• The main application. For all users of the system (mostly manufacturing employees). This will have several working parts to it but for the sake of simplicity, it will display the current jobs that are in the system and filter the results based on different criteria. Users will have cards with barcodes which they scan with a barcode scanner at a Raspberry Pi "terminal" and based on an employee skills matrix, the next relevant job will be issued to them. Each workstation in the manufacturing area will have a sheet of barcodes that represent different processes in the manufacturing of an item and a worker will scan on to begin a process and scan off when it is completed. The times will be collected into a database to be used when the job is completed and for future analysis.

If I was only dealing with Windows machines I would create 3 separate WPF applications for the front end and a data access layer in the back to communicate with the AS400, existing MySQL data, existing job database (which is required for history) and new database for future job data. However, because I need to work with Raspberry Pi's I am guessing I am going to need something in the browser instead.

So... How would folks here go about something along these lines? For simplicities sake I have left out details on much of the other functionality the main application will need to perform. If you need further clarification please ask. I think I have covered the most important aspects.

Seeing how only the main application needs to run cross-platform, should I create the other two as WPF and then use something like ASP.NET MVC for the main application? Should I create a Web API to handle all my business logic and then call into that from my front-ends? Any suggestions would be grateful here.

Cheers.

 

[Skydiver]

Is Xamarin out of the picture for you?

 

[Miles]

Is Xamarin out of the picture for you?

I was under the impression that Xamarin was for mobile development.

 

[jmcilhinney]

Not sure whether there is information of use to you here:

Xamarin and Raspberry Pi

I about to start learning Xamarin for the first time and was hoping I could be pointed in the right direction. Currently I can write ASP.Net MVC 5 applications. I'm interested in communicating with a

stackoverflow.com

 

[NoUserHere]

I'd go with the suggestion in the SO link too because. As a micro programmer myself, it's a viable option for Pi boards. The AS400 is an old lump of wood, and you should consider scrapping it.

Although, if one was going the route of Xamarin, I'd probably lean more on Qt for cross platform development. But that requires knowing some C++. Alternatively, you could also use Python Flask to do the whole lot.

 

[Miles]

Thanks for the replies.

First up, I do apologise for being so clueless. Outside of simple Windows desktop applications I am not very knowledgeable, and even within that area I'm not much of an expert.

As much as I would love to, the AS400 can't be thrown away yet. We have plans to migrate to SAP as that is what our parent company uses but that likely won't be until late 2022 or 2023 and even then there will be a 6-12 month transition period where both systems run side by side.

What I am working with here is a kludge of dozens of Excel files running macros spread over a DFS (some of them are practically full-blown applications), communicating with 5 separate databases (3 MS Access, 1 MySQL, and the AS400), plus Solidworks and AutoCAD VBA macros. Bits and pieces have just been tacked on over the years, some by myself, some by others, but none by people who are actually professional programmers, we are just a bunch of hacks that somehow manage to get things to work, unfortunately, not in the best way. I've been spending more time learning about software development over the last year, and I would really like to build something that is a lot more cohesive, that allows for extension, is a little more decoupled, and definitely more future proof.

The scheduling system will need to work with some of these Excel files and also produce reports in xlsx and csv formats. So I need to have Office Interoperability. I am stuck with Windows. The RPis were nothing more than a low budget solution to allow every manufacturing workstation to have its own computer that could scan barcodes to log start and stop times on the different processes each job goes through, to be used to calculate labour costs and to gather data to be analysed for continual improvement. If it is going to be too much of a burden to go with the RPis then we may need to rethink and go with low budget Windows machines.

Or perhaps I will have to just bite the bullet and start to dig into learning ASP.NET and building an MVC application that I can host using IIS on the Windows Server I have? At least that way I know that it will be accessible from any platform that has a browser right? I'm really clueless when it comes to web development and I fear it is going to be a steep learning curve.

 

[Skydiver]

Web development is easy as long as you follow the KISS principle. Keep It Simple Stupid. It's when you decide that you have to have a particular UI effect, or if you decide that everything has to work Web 2.0-style with dynamic updating screens and support multiple screen resolutions that things become hard.

If you start off by implementing everything as Web 1.0 style where "yes, you have to click on that Submit button and it will reload a brand new page", then it will be much easier. Even better, each of these page submits will give you a very good idea about what needs to be converted into web APIs that your later versions which start implementing Web 2.0 like features will have to call. The APIs will also give you a chance for web assemblies to call back to your server. (I'm betting on web assemblies becoming a major player in IoT devices.) But yes, you'll need to crawl before you can walk and later run, and so your first Web 1.0 version will look like something out of the 90's.

 

[Miles]

Yes, respoonsive design they call it don't they? And I have a little bit of experience with really simple web stuff. I know how to get a basic page up and running using HTML, CSS and JavaScript. I have even done a little bit of AJAX stuff and used newer JS features like async and await and promises. I really don't like JS though. I find it an ugly looking language to read and the patterns I've seen used are strange to me. I am also not a huge fan of dynamic typing. It's a little better in Python than it is in JS though, so I can kind of handle it there.

Should I not even opt for going with the MVC approach to begin with? I have actually written a WebForms application in VB.NET before so I understand how that all works but I would really like to avoid the whole code-behind thing and decouple. I plan on extending this system quite a bit over time. I would just like to get a minimum viable product up and running first and then slowly add to that. What would you recommend I go with, based on the limited experience I have that I've mentioned, what do you feel would be the path of least resistance that would also allow me to extend over time? Keep in mind, I have never built an MVC application before, I kind of understand how it works though. Does using a framework make things easier or will it just add a whole new load onto my already large burden of learning?

 

[jmcilhinney]

Should I not even opt for going with the MVC approach to begin with? I have actually written a WebForms application in VB.NET before so I understand how that all works but I would really like to avoid the whole code-behind thing and decouple. I plan on extending this system quite a bit over time. I would just like to get a minimum viable product up and running first and then slowly add to that. What would you recommend I go with, based on the limited experience I have that I've mentioned, what do you feel would be the path of least resistance that would also allow me to extend over time? Keep in mind, I have never built an MVC application before, I kind of understand how it works though. Does using a framework make things easier or will it just add a whole new load onto my already large burden of learning?

The choice is yours but I would suggest going with MVC from the outset, even if your site is going to be simple. Web Forms is basically legacy now and MVC is where all the new work at Microsoft is right now. There are a couple of other options too but they are much more like MVC than Web Forms. There's no real path to migrate from Web Forms to MVC later, which is why I think that using it from the outset is the way to go. Web API is basically MVC without the views too, so you can build a web site and a web service in basically the same way.

Even though I was originally a VB WinForms developer, Web Forms always felt very kludgy to me. Once MVC cam to ASP.NET, web development felt far more natural to me. You may feel differently but I think that, if you try MVC with an open mind, it will feel right once you get used to it. The drag-n-drop style of Web Forms might be hard to give up at first but it's just not really appropriate for modern web sites.

 

[Miles]

Ok...

So, would I be correct in assuming that I could build a Web API that I can host on my Windows Server using IIS so that all the business logic and state is handled on the server and not on the client machines and then build whatever front-end I like that calls into that Web API which communicates with the various databases and sends back the data to be displayed on my front-ends? And provided I am correct in this, would this also mean that I could have an MVC application that the folks on the RPis use (that the admin folk can also use on their Win10 machines) and also have something else like a WPF MVVM application that runs on the Windows machines for the admin folk who have a different set of requirements for what they do with the data and will need Office interop as well?

 

[Skydiver]

Yes, that approach has a lot of potential.

 

[Skydiver]

In another thread here, the OP there made mention of Avalonia. Apparently it also runs on Raspberry Pi:

Running your app on a Raspberry Pi - Avalonia UI

docs.avaloniaui.net

 

[NoUserHere]

I must be the only one who believes this direction to be a mistake, but that's ok.

I don't know how many web apps you two have fully built in the last few months, but I've built a number of them in C# using MVC pattern, and I fully regret it. Nor would I recommend anyone to use dnc.

Unless the op is using one of the older razor project types, I would recommend steering them in an alternative direction. Otherwise they will be back here complaining about a number of unfixed bugs over the next year or so or however long it takes them to build their app. Time will tell, but as you've seen before Anthony; I've made a number of observations of things which have come to fruition, in the past.

Dnc is not fit for development, let alone production. And there is a lot of evidence of this on various coding question/forum boards.

 

[Skydiver]

MVC5 on .NET Framework 4.x held the least surprises for me and seemed to work well. MVC5 on .NET Core felt like there were always all these gotchas -- and some of them nontrivial.

And yes, MVC6 and higher, specially on .NET Core, always seems to have something that just doesn't quite seem right. I've always attributed it to my just trying to lift code from my older MVC5 projects and drop them into the newer MVC, only to discover that things have changed (subtly or otherwise). I think I've complained about it, and people have pointed out that the same way things have changed between MVC3 and MVC4, and between MVC4 and MVC5, why expect any different with later versions -- as per semantic version numbering there should be no surprises that there are major breaking changes when the major version number changes.

 

[NoUserHere]

I'd rather not be the person to bash Microsoft, but unfortunately almost everything they've done in the last 12 years was a major clusterfuck. Pardon the bluntness, but I am a bit tired of chasing my tail when it comes to troubleshooting issues they should have tested and thoroughly so, before pushing their updates onto developers and customers; as they do. Microsoft developers are idiots - that is: developers who use their products/frameworks and enrol as a 'slave dev'. Most developers spend their careers working with Microsoft code, troubleshooting, fixing and reporting bugs for the main Microsoft development team to patch. In fact, we all have done it, including me. Yes, we do that for them.

I'm sorry but it bothers me that their customers, including developers who use their frameworks to build technologies with, are allowing them to release new and broken variant project types, and in some cases, where the documentation does not match the variant project for a given version. I learned a valuable lesson early on in my path as a developer of Microsoft technologies, sadly one I didn't stick too. " Never use a newly released Microsoft product. " I broke this rule of mine on the second last paragraph below...

I really don't want to turn this into a rant, or a topic bashing Microsoft. That's not my aim here. I love the c sharp language, but I hate the policies of that bloody corporation and how it does things. And frankly, you summed it up well here (emphases mine) :

there should be no surprises that there are major breaking changes when the major version number changes.

Things break when they make major changes. Documentation is often wrong and occasionally misleading. You've made my point for me above. I refuse to be a slave dev. Somebody who attempts to build something unique, hits a brick wall, and then when I ask Microsoft why something is broken or not working as documented, they ask us to file a bloody bug report. Can't we agree it is their job to make sure they supply developers with working thoroughly tested code before pushing it out to the public for production use? Microsoft don't just do this with code. They do it with all of their consumer products. The Internet is littered with posts just like this one, expressing the same frustration. And yet people still recommend people like Miles to use these new defective technologies. Why?

It is inexperience or carelessness to be given such recommendations and advice. If any of you had built a number of web apps from start to finish through 20+ years of knowledge and by use of following msdn documentation, you would find that most of Microsoft's newest releases will cause you nothing but headache, sweat and tears, and in the end, your application will experience a wide range of issues requiring patching. Nor would you be making the recommendations above. Because that is where I am at today. And it sucks. Having used mvc in dnc, it was a disaster for me, and a waste of months of work, and you know what, it serves me right. I should have stuck to my own rule.

The changes are not the problem, the problem is the broken code they produce in those changes. And If you go back through your own recent replies Anthony, you will find yourself pointing reference to Microsoft not following their own API's as well as Microsoft failing to produce non-buggy code, and buggy controls. So I know this is something you and some others on here have likely taken notice of as well. So on that note; the only part of this I would agree with above is using WPF for the admins to use in the op's project. My recommendations above that would take favour over all others at this time.