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.
Related
I have been tasked with moving all SqlDataSource objects out of an ASP.NET pages aspx files and putting them into a separate class file but am lost. Is there a way to create a SqlDataSource object in a separate class and assign query strings to the SelectCommand, DeleteParameters, InsertParameters, etc?
To where you can call the object on a separate page rather than have the code in the aspx?
Yes, you can do that. I would recommend that you move all the database IO to a web service.
I also want to add that this is a very good step that you are taking, as far as the security of your application. Separating your data access from your user IO like this is something I consider to be a must-have security measure. Done right, you will bump up the security of your application significantly.
You can create a WCF web service easily enough. There are plenty of tutorials on the web, and I'll be happy to give you pointers as you go along. The web service would have CRUD (insert, select, update, delete) operations. You can then create an "Object" type datasource on the web page, that points to your web service, and the elements on the page can get their data from those object datasources. You can also instantiate the web service in your code behind, and use it to manipulate the data. When you create the object type data sources, you will specify the service methods that correspond to each of the commands (select, insert, update...). Hope this points you in the right direction, and feel free to ask me more in the comments, or you can initiate a chat and I will give you my email where you can holler at me.
As already mentioned, it is possible to move the SqlDataSource controls out of the WebForm. I'll assume for the moment that your current code declares these controls in the .aspx file. You could change to an imperative approach, for example, and instantiate the datasource controls in an event handler of a WebForm's code-behind class, but you don't gain much by doing so. Indeed, you could even move a lot of the code that does the instantiation into a helper class that is called by the code-behind class, but this doesn't get you much further.
The original intent of the DataSource controls was to provide developers with a way to create rapid prototypes / proofs of concept. But these controls aren't really meant for production systems. They are a violation of the separation of concerns and make unit testing difficult, if not impossible.
In some ways, the DataSource controls can be easier to work with (say, in conjunction with a GridView control). But, this convenience comes at a price, which probably helps explain (in part) why you're being asked to do something with the controls. It's unfortunate that at when ASP.Net 2.0 (WebForms) was released in 2005, the literature that was published at the time heavily promoted the use of these DataSource controls. The community has learned since then that the production value of these controls is questionable, unless you are working on simple systems that don't need to evolve much over time.
As was mentioned by Anon316, you could use a web service to handle the CRUD operations. However, this solution might not be what you really need. Additional overhead is incurred by using a web service (i.e., additional HTTP requests to the service). Having your application make direct calls to the database can still be a very good approach.
With that said, consider creating a separate class (or classes) that provide data access facilities (e.g., a Repository). Entity Framework, for example, makes creating this kind of thing fairly straightforward (and there are many other data access libraries available in the .Net ecosystem). Be prepared for adding more code to the code-behind classes of your WebForms in order to make them interact with your Repository (or other Data Access) class(es). The benefit you'll gain is more testability and reuse of your data access code. Consider putting your data access class(es) into a separate project in your solution (to start).
Whether you create separate data access class(es) in your solution or a web service, you still have significant refactoring to do in order to move away from the DataSource controls. So, again, be mindful of the additional overhead involved in using a web service, recognizing that a web service tends to make sense when you have multiple clients (e.g. web and mobile), not when you only have one.
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.
I'm currently trying to create an application with Prism and I have some problems with communication between modules.
I have a StatusModule which basically shows Statusmessages, but can also show the user that some work is in progress (indeterminate), show different icons, show / hide the control and so on.
For that normally i'd use a status object that has all these properties and use it as a parameter, but because in prism strong coupling is advised I don't know how I should do it.
Creating 4-5 Events for every property is probably bad practice, .. i also thought of creating an interface in my "Interaction" Module where the event's and resources are.
What would you guys recommend?
Many events for status might indeed not be the best solution; however if there's one or two that are used a lot (like showing a status message in a statusbar), I would expose them as events anyway for convenience.
For the rest, you can expose the StatusModule, or rather an interface IStatusModule that is implemented by StatusModule, via MEF or Unity depending on what you use. This way any component that wants to show status imports the IStatusModule and uses it.
The project I'm working on is quite large and we have a framework we developed for building simple UI screens easily. The two fundamental types we have are Search (search parameters + grid of results) and Detail (a set of editors that are usually populated from some model object).
The application is all C# .NET Winforms.
In the Detail we have the following process.
Load - Populate the edit controls based on the appropriate model object. Invoked just prior to the Detail being shown
User clicks ok
Validate - Validates the detail to ensure everything is consistent
Accept - Copy the updated control values back into the model
This all works nicely for simple stuff but in more complex cases I've noticed perhaps the above approach is not the smoothest.
The more complex cases mentioned above are when a Detail represents a model object and there is a grid embedded in the Detail which holds 'child' objects which can be added and removed. Typically you want to launch the child Detail and pass in the parent model object, however it is not fully populated/up to date at this point because that only happens when OK is clicked. I find myself working round this in an annoying fashion sometimes which leads me to the following question.
At a high-level, is the accepted/best practice approach for Detail screens like I describe to copy values to the model object when the control is changed, rather than waiting until OK is clicked?
If so, in a Winforms app, what is the best way to achieve this? I found some articles mentioning Control.DataBindings but it's not ideal because of the lack of compile-time safety on the binding. I've read WPF has good binding support, but unfortunately, I'm not using WPF.
For Winforms I would suggest that you look into the Model-View-Presenter pattern.
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
This might help:
Walkthrough: Creating a Master/Detail Form Using Two Windows Forms DataGridView Controls
http://msdn.microsoft.com/en-us/library/y8c0cxey.aspx
I am currently writing a little game with standard UI controls.
It is working great so far but what I don't like is that I am managing the controls in the codebehind file. (C#)
As I am trying to decouple all elements, I would like to have a separate engine / controller which handles all the data management and the logic for my user interface.
Is there a possibility to register the controls with the engine so that I don't need to pass them down with every method I call?
Currently I am forced to pass the controls every time I call the function..
Thanks in advance!
Will be good if you can elaborate more on your current implementation. From what I can understand, instead of trying to figure out how to 'register the controls with the engine', why not try to see if it's a design issue.
Perhaps there's a better way to structure your app/classes/components so that you can decouple logically for better reusability and maintainability?