I'm creating a signal analysis program that plots some data and compares sources and does some operations. I'll have to update the size of some elements of my UI and also create new elements (for example, I have a big plotter, and if user selects X it should to divide in 3 showing more data).
I'm pretty new in Visual Studio and in programming non-numerical stuff in general. I would appreciate enormously hints and advises to create a solid interface.
One of the issues that I currently have is that I've defined 15-20 elements in MainWindow.xaml and its code in MainWindow.cs but it's growing fast and it is a mess. For example, I have a button that loads a file and does a bunch of different operations (reads it, cuts, puts all in lists and then displays it). What do you recommend me to keep the code clean and readable? To create methods at the end of the file? Create separate class files?
I know its not very specific question but I think I'm not the only one that is having this kind of problems. Thank you.
A class with some static helper methods is a start. There are lots of different ways to go with this, but the main point of all of them is your MainWindow.cs should have only enough code to gather information together in the UI and then call on the other layer(we'll call it the business layer) to actually perform tasks or save/load data. MainWindow.cs should be like a seperator between your UI and your business layer. The business layer shouldn't know anything about buttons or textboxes. Instead it might take the string from the TitleTextbox and put it into a SignalFile.Title property of a simple class(called a POCO). You might have one business layer class that deals with operations related to this file, a method for each action you can perform on it.
Related
I'm trying to implement Blackjack via Visual Studio, but have just been introduced to it. Suppose I have a PictureBox representing a card in a hand. This box starts with an image of a face-down card, representing a card slot that hasn't been dealt to yet. I have a function in my Form object that changes the PictureBox image to another card image resource based on an integer parameter. This is all pretty standard.
What I'm having trouble with is actually calling the method from main. I could create a new Form object and set the auto-generated one to invisible, but I'd rather work with the form that's auto-generated. Should I just put all the game logic in the Form1.cs file? Does the auto-generated form object have some default name I can use?
I realize this seems pretty novice level, but it seems like Microsoft's support documentation would prefer you create entire projects from the designer view and doesn't help much for actually coding.
The typical model for a simple Forms program is to allow the Main() method in Program.cs to remain in its default form: set some things up, create an instance of your primary Form subclass (the class name by default will be Form1), and pass that to the Application.Run() method.
It is good design to have a "controller" object outside of the UI object. But especially if you are starting out, you may well find it simpler and easier to understand if that "controller" logic is also in your primary Form subclass.
In that case, yes…all of the code winds up in the one .cs file, and indeed in the one object.
Even with the controller logic in the Form object, you will still find it useful to keep the code that is essentially controller logic separate from that which is user-interface logic, and to use the C# #region directive to label these sections of code. That will help you keep a mental model that still separates the two roles within the same class.
Beyond this, there are lots of differing opinions, from the complete "shoot-from-the-hip" approach, to the extremely strict and rigorous adherence to specific design patterns. But the above is consistent with the pattern that the Visual Designer leads you to, and so is a fine place for beginners to start.
I have some GUI controls in WinForms application. For example i have log control which logs each progress application makes so i can debug quickly, currently all "databinding" is on MainForm. I can create separate control but still it is coupled too much with application logic.
I've got advice to use partial MVC pattern in which I will update some object which saves log items and log control will get to this object and load the data to control.
I don't know how to implement it, besides creating a Class which will hold the data I need to load.
I have problems with Threads as many processes in the application run in different Threads.
Do you know any example of this done in C#?
I read the thread Mr Moose links to, but what finally got me going was this: http://www.c-sharpcorner.com/UploadFile/rmcochran/implementing-the-passive-view-a-derivative-of-the%C2%A0model-view-control/ is part of a series the guy wrote on this exact issue. I am currently using this scheme and am quite happy with it.
I added a ObservableDictionary to some of my Model classes. Key based lookup is nice for a lot of cases.
He has a whole series of articles with different implementations that may be more suitable for you.
I've written a simple desktop application with C#/WPF and I'm now looking to create another, larger application which will share much of the functionality. I'm thinking that I should create three separate projects: one containing the shared code, and one each for the two apps.
My problem is that I'm not entirely familiar with .NET/WPF so I don't know if there are some best practices for this sort of thing. Can anyone offer some good sources of information, example projects or just some brief advice?
Edit: To put a little more detail on the scenario, the first application is a specialised editor and the second application is taking this file editor and wrapping a project model around it to create a sort of basic IDE.
Honestly it depends on what level the code you intend to share is. For instance, it's entirely plausable to put all of your business logic code into one project/class library and maintain it independantly, but mixing biz logic with WPF custom controls should be STRONGLY discouraged. Think about the layers of abstraction you are modularizing, and the dependancy heiarchy you are introducing and refactor accordingly.
Edit:
In response to your above changes I suggest the following: The logic and DAL associated with the above should be pushed into a project as seperate namespaces. The visual elements (the view, viewmodel) should most likely be moved into a seperate project and namespace set as well. Once you can merge these together and launch them from an exe that contains a host window and a UserControl for the rest of your hosted visual content, you can then probably move forward with integration into your larger IDE project. The key here is:
Visual Layer and View Logic -> Editor.Visual.dll
Biz Logic & Data Access -> Editor.Core.dll
I hope this helps.
I have a sample ASP.NET application. The appliaction was developed as POC and not following any design and architectural standards.
Now I want to restructure the application. I can see some of the business logic and controls can be reused in future, such as login control.
I have two options for restructuring
I create a Utility DLL that will contain all such resusable code and another DLL that will contain all controls that can be reused.
I will create a separeate DLL for each type which can be reused e.g. Login control.
Which option is more better. Although I feel option 1 is good, but I need suggestion from experts.
I have no idea why you would want to keep a separate assembly per type. Don't do that.
Keep related functionality together in a single assembly. Look at how the .NET Framework is organized for examples. Note how, if you're not doing data access, you don't need to reference System.Data.dll.
There are multiple ways to build an architecture. For instance you can create horizontal layers which put all GUI logic, business logic and data logic into separate layers. This is only from logical perspective. Where to put the layers is another question. From OO perspective you put them in at least different classes. You can decide to put them in different name spaces, different project/assemblies.
Just start slowly and refactor the most obvious parts. You can start putting the classes together in a part of the project (folder). Then change namespaces. Then put them in seperate project. Small actions will give you the chance to further consider your options. Each improvement is one.
So my advice is to first arrange classes and namespaces within the current project and so shape the logical parts. Maybe you need to add some interfaces here and there as well to separate the layers.
I would go for a single assembly for your controls. You might create a new assembly for controls which you probably won't use soon or are very special.
I would categorize the business logic and make an assembly for each category.
I'm attempting to refactor an existing Winform application to use the MVP Passive View pattern. The application's UI, business logic and data storage code have been freely intermingled for years. It looks like it either started out with separate layers or someone attempted to separate it into layers. In any case the layer boundaries weren't respected.
Since the forms directly manipulate the domain objects and the data source(and vice versa), my first task is to create presenter/controller objects and delegate those responsibilities.
The application is a .NET 1.1 app and I'm developing in VS.NET 2003 with a rather limited refactoring add-in. I used a test generator for the existing code to create the boiler plate unit tests then went through and hand edited each test. Granted, this winds up testing what the code does, not necessarily what it's suppose to do. For new classes I'm doing TDD.
Any tips, resources, pitfalls to look out for with a refactoring effort of this scale?
A couple of resources I already have at my disposal:
Collection of programming books; Refactoring, PEAA, WELC
The internet (obviously)
Large quantities of caffeinated beverages
Update:
As an example what steps would you take to turn this:
private void OneOfManyFormEventHandlers(object sender, System.EventArgs e)
{
string LocalVariable;
decimal AnotherLocal;
if (!this._SomeDomainObject.SomeMethod(ClassField, out LocalVariable, out AnotherLocal))
{
MessageBox.Show("An error occurred calling method");
return;
}
this.FormControl.Value = LocalVariable;
this.AnotherFormContorl.Value = AnotherLocal;
this.AnotherPrivateMethod();
}
Into this:
private void OneOfManyFormEventHandlers(object sender, System.EventArgs e)
{
this.FormPresenter.DoSomething();
}
The approach I've taken is too move the code out of the event handlers first. Essentially I've placed a class next to the form, which implements the event handlers and holds the UI state beside the controls.
Through this move I have gained a pretty clear seperation of the form and the actual interaction with the remaining app and was able to introduce tests at that level. Another result of this was that the view becomes passive pretty quickly.
I refactor the presenter (which now holds the event handlers) in a seperate step and introduce domain objects only after I've moved all uses of these objects out of all forms.
So my steps would be:
Remove the UI dependency from the logic
Create domain objects (if not available already)
Refactor the presenters to use the domain objects
Introduce services according to your design choice while you're at it
While I did this I started introducing tests at the newly introduced boundaries to ensure that I'm not breaking working code or to find bugs in the existing code I'm moving.
If you have the time, I'd recommend first writing some smoke tests using WinForms test frameworks like White on the existing application. This way you'll be able to check for any newly introduced bugs when you start refactoring the code.
You may find the answers to Implementing MVC with Windows Forms helpful as they talk about the different options when implementing MVC and MVP