Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm writing an application in WPF and found myself loving whole MVVM paradigm. My only concern at the moment is that my ViewModels are becoming heavy. They contain Commands, logic to enable and disable buttons, instances of other ViewModels, async method with DispatchTimer timers etc. Is this something that is normal in this kind of development environment? Or is there some logical way of organizing ViewModels without becoming too "crowded"?
Keep in mind that the ViewModel is just an adapter between your model, where logic and data live, and the view which is shown to the user.
The idea is you can easily swap views or change them, without the logic suffering from that.
Having said that, depending on the complexity of your application, they might grow quite big, but if it's mainly stuff that ends up enabling/disabling stuff on your view, and isn't doing logic / processing stuff, I'd say this is where it's supposed to live.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Some 30 years ago, I developed a big app for fresh fruit packers. I followed a nice paradigm, taken from Informix-4GL: the same screen allows the user to set a "query by example" or to insert a new "record", or update one of them after a successfully one. It maintained a "current list" (the resulting query result and the new records added) wich could be navegated with PgUp and PgDwn Keys. Of course, all that stuff was expressed as mapped text.
The very important thing is that the screen was idle until the user did a "command" to start a new query, an insert or update (or even a delete) operation.
Now, it's the time to evolve that app.
I'm thinking in Wpf and its Preview* group of routed events, to catch the main user "command".
But because there are lots of screens (near one for every entity in the database) it's important to set what is common between them.
Is it the best way (in Wpf) to set one or two "super classes" of Windows for this approach?
TIA
Technically — sure, you can create a class that inherits from System.Windows.Window, have all windows in your app inherit from that one, and implement some common logic in that class.
However, this approach is not considered a best practice for WPF and other XAML-based platforms. Your window and other GUI classes should only contain code specific to presentation. Your model classes that handle the DB queries should not depend on the exact GUI you’re using to present these models.
While not required, a third-party MVVM library is helpful to e.g. provide design-time models for the IDE. As for the specific library, lately I prefer Caliburn Micro, before that I had positive experience with MVVM Light.
With MVVM, it’s fine to have a base model class with some logic that’s common across different model classes. In fact, many libraries encourage you to do so. They provide their own base classes for your models. Such as Screen or PropertyChangedBase from Caliburn Micro.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am short on time,and I need to develop a desktop app that will be used in a firm.
I dont have time to learn mvvm or any other design pattern.
Can I develop an app without it?
I did some basic sql crud with a table and it works fine,but I wanted to ask you if I can develop a whole app without some of this design patterns.
EDIT: You can do it,but you have to be carefull,also there will be more effort included if you want to edit some things down the line.
You don't need to rely on MVVM when using wpf. Really the keys to
using wpf properly are:
-Use commands instead of events (you might do this without realizing
it, but check to make sure)
-Use data binding instead of getting values
off of controls directly
-Set the data context and bind to that instead
of binding to the code behind
MVVM works really well for these two
things but is not required. Specifically, MVVM requires a 3-tier
strict separation of concerns that can just as easily be done with
MVP.
Source :
Developing WPF software without MVVM
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
How would I go about implementing something in C# for iOS, that looks and feels like the MonoTouch.Dialog controls, without actually using Monotouch.Dialog?
It is the same amount of code if you use ObjC or Xamarin.iOS. Just slightly different syntax.
Your alternatives are
MT.Dialog (if you want to do the UI in code). This will dramatically reduce the complexity and MT.Dialog was designed exactly for the creation of quick and simple settings screens. In most cases, you will want to subclass the predefined elements to get best results.
Static UITableViewCells if you want to use Interface Builder. This allows you to create your UI in IB (or the iOS Designer built into Xamarin Studio). You can find tutorials on the web, like this one.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Recently I'm reading an article about http://ardalis.com/n-tier-design-lessons-learned-part-1 which introduce the evolution of n-tier application but one thing was not explained is the WorkFlow layer can anyone one explain what's the workflow layer and give us a real world application example with c#.
From here:
By creating a workflow tier a company has essentially avoided
hardcoding workflows into one of the other tiers. By creating a
workflow layer, we will gain the added flexibility easily
customizability that a tier provides. We will gain improve
manageability of the workflow tier by extracting the layer. For
example, when the end user requests changes to the workflow, by
creating a specific workflow tier and thus isolating the
responsibility of workflow the resulting code changes will be
minimized to just the workflow tier. The impact on other tiers will be
minimized.
Also check To Workflow or Not to Workflow?