Web Application VS Windows Application

scottalanmiller

dear Scott please can you tell me what are the right steps to follow when working with document DB ?? i mean are there any models to follow in document DB similar to Merise or UML in relational DB ??

No, I don't believe any modeling tools like that have been created yet. Although the need for them mostly does not exist.

scottalanmiller

Try this, take Word and try making a sample "document" of sample data for one or two users. That should, mostly, guide you as to what the MongoDB document will look like.

Do it something like this...

First Name: John
Last Name: Doe
SSID: 123.45.678
Cell Phone: (132) 465-7896

Something like that.

IT-ADMIN

wow, how it can be arbitrary like this, no rules, no models to follow,
strange

scottalanmiller

@IT-ADMIN said:

wow, how it can be arbitrary like this, no rules, no models to follow,
strange

There are rules, they are just more lax and flexible. Maybe a better question would be... what were all of those rules for?

IT-ADMIN

ah i see, so there are rules, can you please give me any guide how to start a project using document DB from A to Z, because really i'm lost in this stage, document DB is new for me and i do not know where i should start,
you can imagine someone hear something for the first time and he is ignorant of the steps he should follow

IT-ADMIN

before with relational DB, we establish the conceptual model that include all entities of the whole project and the relation between them (one to many or many to many) then based on the entities we create tables and start developing the app based on the model, but now i'm lost with this new methodology of DB,
between us i really found this document DB very useful and easy but i'm still unable to put my feet on the right way

scottalanmiller

@IT-ADMIN said:

between us i really found this document DB very useful and easy but i'm still unable to put my feet on the right way

I think that you are overthinking it. Try taking the data that you have and instead of thinking of a place for each "type" of data, make a single document for a single user/person and put all of the necessary data into that document. The data remains related by the nature of existing within a single document. If you look at the data that you have in a relational design, you can assemble a document by doing a join on it. Instead of data all over to assemble to a user, start with the data in one place.

And try not starting with the database, start with the application. You don't need to design the database at this stage.

scottalanmiller

@IT-ADMIN it's been a few months. Any follow up on your development project?

scottalanmiller

Pinging against in case this got missed @IT-ADMIN

tiagom

Long thread for me to go through on my phone.. But another option since you mentioned vb.net that may have already been mentioned is to publish it as a clickonce application. I use that on a project and it works well.

In my case Click once does not need administrator right to "install" and handles updates automatically.

guyinpv

Desktop apps have their place, this is silly.
A native desktop app can better utilize hardware, take advantage of native OS abilities that chromeless frameworks can't.

Native apps can be built in lower-level languages and be built to be much more solid, speedy, use fewer resources, take less RAM without all the middlemen fluff.

I'm all for web apps, they are cool and all, but they depend on a browser and a tab being open. They have limited abilities, they can't even put an icon in the system tray, or startup with Windows. They are not as easy to control via OS security policies.

Maybe I just have bad luck, but I ALWAYS try to find services that give native desktop apps. If not native, then at least full featured frameworks that can use native OS features.
I rarely touch Office online because it's just slow, herky jerky, buggy, crashy. I absolutely hate interfaces that aren't very responsive.

I agree with Scott that IF the app can be a web app, go for it. But there are also times when you might want native OS features, lower level language that compiles with fewer dependencies, smaller size, greater efficiency, and so forth.

Apps can be built to self-update, most desktop apps do. I've never had to do anything fancy to get Slack to update, it just updates itself. Slack isn't native, it's a framework, just using it as an example.

I think when the OP talked about Windows apps being "buttons and boxes" or whatever, he probably just means that there is a drag-n-drop interface for common .NET form controls. You just place all the controls where you want and program from there. Things like minimize/max/close, resize-able borders and control menus are all sort of automatic.
But with web apps, form libraries are not as popular, and there aren't any really good drag-n-drop designers for creating UI FROM such things anyway.
Much time has to be spent designing the UI, even if you do use a library (you have to learn the library!), or even a CSS framework like Bootstrap or Foundation, you still have to code and try to keep straight the rows and columns and how you want things to respond and slide around responsively.

In any case. Desktop apps definitely have their place. I use desktop email, desktop photo editing, desktop file and information management tools, chat, backup apps, file sync, document readers, DB management tools, remote control tools, FTP, text editors/IDEs, and 3 dozen others that are just way more better suited to native.
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
And of course, browser tabs are, for the most part, sandboxed, so there are already limitations regarding file system. Try auto-connecting to files over the local network from a web app. Web apps don't have unlimited power, if they did, we would be right back to having huge malware issues. Malware has made web apps more limited and locked down. Native apps are still the way to go if you need power and greater control of OS abilities and features.

This web versus native argument can go forever, but just like most things in life, you pick the best tool for the job. If a web app will do it, always go web app. They are typically easy to set up and maintain. If you want native OS features or require to greatest efficiency, security, or OS-level features, then obviously native.
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.

I believe cross-platform frameworks are going to be huge for some time to come, but there will always be a special place in my heart for a native app that can fully utilize system tray, startup, notifications, file system, and full system power.
Yes frameworks can do some of this, but they have to come with a lot of middlemen architecture, bloating the apps RAM use probably 3 to 5 times more than would be necessary with native programming.

Anyway, I've rambled on long enough.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

Desktop apps have their place, this is silly.
A native desktop app can better utilize hardware, take advantage of native OS abilities that chromeless frameworks can't.

Native apps can be built in lower-level languages and be built to be much more solid, speedy, use fewer resources, take less RAM without all the middlemen fluff.

CAN be, yes. But very rarely do any of those things matter, especially for business apps. Those are things that apply very commonly to video games, and once in a great while to business apps (CAD for example) but almost never.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

I'm all for web apps, they are cool and all, but they depend on a browser and a tab being open. They have limited abilities, they can't even put an icon in the system tray, or startup with Windows.

I have web apps that can do all of those things.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

They are not as easy to control via OS security policies.

I'd argue that that is almost always a good thing. OS policies are the wrong place for the majority of app management. It's similar to relying on the LAN for security, it was necessary long ago but mostly crufty today. You can move security into the central app for better control.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

I rarely touch Office online because it's just slow, herky jerky, buggy, crashy. I absolutely hate interfaces that aren't very responsive.

I actually have the opposite experience, even with MS Office. Neither experience is great, but it's often better online. But a lot of that is because it's a web app even when running locally. Like many modern apps are. It's become common to make things that look like native apps but are actually web apps.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.

What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

If you want native OS features or require to greatest efficiency, security, or OS-level features, then obviously native.

Partially this is true. But web apps have nearly unlimited access to native features today, including OS level features, are often super efficient (often better than native because of better coding) and I'd argue that security is backwards, native apps have the biggest security challenges.

scottalanmiller

@guyinpv said in Web Application VS Windows Application:

If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.

Just web apps running locally It's not really a crossover. You can do all of the same stuff without those frameworks using web apps. The web server can be local.

Dashrender

@scottalanmiller said in Web Application VS Windows Application:

@guyinpv said in Web Application VS Windows Application:

Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.

What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.

sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.

scottalanmiller

@Dashrender said in Web Application VS Windows Application:

@scottalanmiller said in Web Application VS Windows Application:

@guyinpv said in Web Application VS Windows Application:

Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.

What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.

sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.

Right, but it is still extra risk. The choices are, in that example, require only Exchange or both Exchange and Outlook. Outlook doesn't reduce the risk, it increases it.