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 4 years ago.
Improve this question
I'm developing a desktop application that serves as an IDE for our customers. This application allows the user to configure and integrate our programmable devices into their products.
I'm looking for best practices/design patterns for managing persistent data in an MVVM app like this. Some data is potentially reusable between the users' projects, so I'd like to store those pieces independently, rather than in one big file. This scenario has led me to consider the way Visual Studio handles this (a .csproj file that points to the files that make up the project).
When considering the Visual Studio approach, I can easily implement an object like this for my own data and serialize it into XML. However, when it comes to opening and manipulating the files that this project file points to, I am really struggling to find an elegant solution.
For instance, I open my project file, deserialize it, and I'm left with an object containing the paths, as well as some metadata like CompanyName, ProductName, and so on. Next step: open/deserialize each of the files pointed to in the project file... But where should those objects live? How should you notify the ViewModels that the model was changed externally? Intuition tells me that there should only be one instance of any unique model to avoid issues with copies falling out of sync, but that's all I've got.
Perhaps there's a framework available for this?
There is probably a good article or SO answer to this, but I couldn't figure out how to search for it. Any advice would be greatly appreciated.
Settings that are specific to the application should be stored using the normal settings that's built into Visual Studio and .Net (Settings tab on project properties). This will provide you will versioning, upgrading, etc.
Settings that are specific to each project would need to be stored in the project itself.
To be a good corporate citizen, you should create a folder off of the user's Documents directory and then each project might have its own sub folder if it has multiple artifacts, or I guess just a flat directory if everything about the project is a single file.
The other part of your question was unclear. Are you talking about how a .cs file can be edited externally to VS and VS reloads it automatically? If so, you'd just set up a file change notification watch when you open a project.
EDIT:
View models should generally not have references to each other, unless you are referring to POCOs that implement INPC as a "view model" which I don't really. View models to me is basically the data context for a XAML view.
In terms of VMs communicating with each other, its best to keep it loosely coupled and use the messenger pattern. Most MVVM frameworks have a messenger implementation. You DI a IMessenger or whatever interface they use into your VMs and then IMessenger.Subscribe<OpenMessage>() (syntax obviously varies among MVVM frameworks, but in general you get a message of type X and add an event handler or call the send method) for example and get notifications of that type. The VM that is initiating the message would new up an OpenMessage and send it to the messenger to distribute it to the VMs that want it.
For your CsProj scenario, you would need to store those settings in the project file and deserialize.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 11 months ago.
Improve this question
I have a VERY SIMPLE application which is supposed to read a file selected by the user and display it on the screen. For that I created two views, one with a button for the user to select the file and another view for displaying the contents of the file.
I also have two ViewModels one for each of the views, now, when the user clicks the button to select a file the code in the ViewModel will use OpenFileDialog and open the file, my question is should I call OpenFileDialog from the viewModel or from the Model for a MVVM project?
Dialog boxes don't fit into the MVVM paradigm very well, due to the tight coupling they have with the OS. As a general rule though, anything you want directly unit-tested belongs in the view model, while anything that creates Windows GUI objects at runtime belongs in your view layer. With that in mind, the view is the appropriate layer for calling OpenFileDialog. You may find that you still need to break the clean MVVM architecture to do this, so abstracting it away into a service that can be injected will at least keep it away from the rest of your code and maintain good seperation of concerns.
If you really want to do this properly then you have to implement some boiler-plate code similar to what the WPF team wrote for "regular" windows. I wrote a long article about it here, along with a library for easily adding dialog box functionality to your own MVVM projects:
https://www.codeproject.com/Articles/820324/Implementing-Dialog-Boxes-in-MVVM
I am trying to make an application that will load sports data (teams, players, games, etc...) from API and save into the database (with an update once a day) for subsequent analysis (in C#, but I think the language is not that important). The application composes from two parts, one for GUI and second for working with database and API.
My question is: Is it a good idea to use the same classes eg. for teams or players in model for both API and database? I know that one class should have one responsibility, but separate classes seam to me like a little overhead and even bring complications. But maybe I am wrong because I donť have enough experience with architecture design.
Thanks for answers.
If the two classes are the same class that should serve both projects, you can create instead a shared DLL holds you class by adding additional project to your solution, write the class you need and reference it to both project.
This will make your DLL to be apart of the two applications without writing your code twice.
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
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI
I have a scenario that i have never come across and as such require help. I created an Visual Studio Web Application. The solution had two parts.
Project that holds all the UIs and
a Model that contain my c# code.
The objective was to achieve a 3 tier architecture. The model being the middle tier. The project is running and everything is awesome. NOW! This is my situation and I dont have an idea on how to approach it. I have to build another application, which basically is an extension of the first one. So how I went about starting this was to add another WEB Project to my currently solution. This had a lot of problem. When I deploy the project two web pages would load (one from each project). What i want is ONE webpage to load and base on your userId it will send you to the appropriate location. What I also saw was the second web project i added needed it's own users. How it should be is.. one set of users each having specific access to the application (which ever part). I need input on how to go about getting this done.
What I want is to debug 1 solution (with the 2 parts/projects). Base on userId he/she has access to a specific project but there is one user list that governs the entire solution and not two list, one for each project.
Is there a problem just adding pages to a directory in the existing web project? Normally, separate projects would be deployed as separate applications, not as merged into the same application. You can control access using web.config files in the "secured" directories
Another Architectural suggestion would be to create a Main web project that was sort of a wrapper if these applications are extensive enough and functionally dissimilar enough to warrant separate projects. This would be where your routing logic would take place and would provide simple stub directories for your paths (user-type 1 ... user-type n). Then you can create a project for each of your end paths and set some build actions that take the output of the sub projects and copy them to the output directories for the wrapper project, but this gets pretty complex.
I would still recommend keeping this as a single project if it is to be deployed as a single web application.
While it's possible to make this work as two separate systems, it's really a lot more headache than it's worth in most cases.
The question you should ask yourself is, is it really worth it to do this? What are you gaining from it?
This article explains how to do this:
http://support.microsoft.com/kb/307467
Another option is to create sub-sites, which is to add your additional project as a child. This is described here:
http://abhighag.blogspot.com/2012/03/separate-web-application-into-multiple.html
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
Basically, the question is: Where (and in which format) should I store textual developer documentation associated with my Visual Studio projects?
To elaborate: XML comments are great, but they don't cover all use cases. Sometimes, you'd like to describe the class architecture of the project at a high level, add usage notes to your library or just leave any other kind of message to future generations of developers working on this project.
I'd like to add these documents directly as files into the Visual Studio project, to ensure (a) that they are available to the developer without further searching and (b) they are version controlled (using the same svn/git/whatever repository as the source code).
Currently, I add a folder _Documentation to the project and use text files, but I'm not sure if this is the best solution. Visual Studio does not have an option for automatically word-wrapping text1, and manually fixing line breaks after each change is annoying. On the other hand, Word documents don't work well with version control, and TeX is too much of a hassle to set up and teach on each developer PC.
Is there a well-established best practice for this?
1 I know that there's Edit/Advanced/Word-Wrap, but this only affects the display, not the file itself.
I just had the same issue - only I noticed that I was able to add a HTML-file. Once opened, simply switch to "Design" at the bottom of the screen.
You may want to change Build Action from 'Content' to 'None'
As it is a hard-coded HTML document, it is also possible to use inline pictures (e.g. a diagram)
Also for my purpose (programming guide, architecture description. database use examples) I opted to create a separate project (_Documentation) as a Windows Forms, as this will allow me (or a new programmer) to have a running example.
I use GhostDoc (visual studio add-on) for documentation of my project as I add classes, methods, properties etc: http://visualstudiogallery.msdn.microsoft.com/46A20578-F0D5-4B1E-B55D-F001A6345748
You have the option, in XML comments, to include a lot of data that you can then pick up with a tool like Sandcastle (site) and turn into an actual MSDN-style reference site.
I tend to use this method and just write long XML comments (MSDN comment tags) (where appropriate) using the <para></para> to generate paragraphs and explain any patterns, business reasons or architectural information necessary to future modifiers/developers. I also use it to give usage examples.
A good batch of tests (well written and named) can also really illuminate the purpose of code, acting as a spec.
I hope that might be a little informative in your research :)
XML Comments is best for documenting the particular method and not ideal for writing long conceptual content. Long XML comments could adversely affect code readability.
I liked Conceptual topic documentation feature of Sandcastle, we can create and store Conceptual documentation whether functional or architecture related and merge it with Code documentation (XML Comments). Markups which you can use in writing the conceptual topics are extendable which means we can even adhere to Enterprise templates.