I am developing a winform application where a set of classes and its methods calculate a geometry from 3d points.
As there is some input from the user needed from step to step in the algorithm we have designed some buttons which represent the steps. The intermediate data is stored in a class (maybe we use a structure in future Versions), so as the user input is. As result of pushing the Buttons the intermediate data will be calculated, saved and shown to the user, so that he can edit it, affecting to the calculation in the next steps.
The application began as an application which calculate everything in 4 steps but now we have more than 10 steps so we have divided it into 3 parts (horizontal geometry, vertical geometry and other...). Now I am doing some divisions because everything is getting too complex to manage all the gui interaction in one Form so I will create user controls for the smaller parts of the form.
Do you have general recommendations for me?
Should I have these data structures (input and intermediate data) in the controls I make or in the general form?
You should avoid mixing UI with the business logic. In that way when the program grows larger it will be a lot easier to maintain. It will also make it much simpler to write automated unittests.
If there is no particular reason you are using winforms. I would recommend using Windows Presentation Foundation (WPF). Read a tutorial about the Model View ViewModel (MVVM) design pattern. This is a very nice way of separating the UI logic from the business logic.
It takes some effort to switch from Winforms to WPF but it is definitely worth it.
EDIT (answer to comment)
Well it depends on the problem your solving. But generally:
In the MVVM pattern the:
Model would contain all your data and algorithms in classes/methods. The ViewModel would connect all the stuff you have in your Model and control the flow of the program, it will expose properties (commands, strings, numbers collections etc...) that view can bind to. The View is simply a "skin" that makes it possible for the user to communicate with the ViewModel. This is a very simple explanation of the MVVM pattern and I would recommend reading a tutorial about it.
The first time I came across this pattern it was called Model View Controller MVC, I like what AngularJS is doing by just calling it Model View Whatever MVW because there are a lot of MV* out there. But WPF is specifically built for MVVM.
The most important thing, if your creating a program that is going to be used and maintained for many years, is to keep the code as simple as possible. Instead of writing all the functionality into the Button_Click event handler (I have seen some programs that do this), try to write a class or method for every single task (use long descriptive names), this is also called Seperation of Concerns. In other words one method/class should not do more than one tasks. The nice thing is that you end up with a "program flow controller" (ViewModel/Whatever) that just passes data from one method to the next. And just by looking at the code you go: Aha I know exactly what is going on here! In the same way when you look at your algorithms (Model) they should do a single job and all variables should be have descriptive names. This makes it very easy for other developer to understand the code.
I also have very good experience with dividing my namespaces according to type. So every time you have more than one object of some sort (DataProviders, FileReaders, etc...) create a namespace/subnamespace for them and put them in there. So when your creating a new object/interface/enumeration... you always know where to put it. And you always know where to find again: Oh its a DataProvider so it must be located in ProjectName.Objects.DataProviders :)
So my recommendation is: have some fun and read about: MVVM and SoC
Probably state machine diagram will help you do devide actions in parts. It's a better practice, to create some of diagrams before codding.
Related
I'm learning .net mvc through making a web application.
I have a page for a list of items(for example a list of properties). How should I generate the urls for each of these item? Inside each url there would be a page for more detailed information of the item. Should I manually create each view for each item? There could be thousands of them. Any advise on any tools or methods I could use? Thanks!
This is a pretty broad question. The identification of opportunities for generalization vs. specialization is one of the most important competencies for a software engineer. And there are a lot of variables.
Two principles you should be aware of:
Keep it Simple Stupid (KISS)
Don't Repeat Yourself (DRY)
N.B. In many ways these principles are in opposition to one another.
You could build a web site with one view for each product. This is pretty rare because you'd have to build a lot of views. On the other hand, if you only have a few products and you want to highlight their features using a custom layout (for example, visit Tesla.com), you might develop View for each and every product. This does keep it simple, but you may end up repeating yourself a lot.
More commonly (e.g. Amazon.com) there will be one "Product Page" view with code that customizes the page (e.g. fills in the text and image areas) per product. This is a much more scalable solution, although when you do it that way you need to take the time to develop a rich and flexible data model, because you need a uniform way of representing the content on the page in a database so that the code that populates the View can be completely generic. This avoids repeating yourself, but it is less simple.
Then there are solutions that are in between. Maybe half of your products can be represented on a single type of page, but some of them need a different layout (e.g. need to include a size/color UX, or include spec sheets). So you may end up with a half dozen views, one for each type of product, that cover hundreds of products.
What about other pages? Like search, homepage, etc. Well you will need a separate view for each page that is different enough that justifies splitting it off from other views. For example, if your Search Results page and your Browse By Category page look very similar, you might implement them with a single View and write code to tailor some details about how they look (e.g. change the title). On the other hand, if they are pretty different it may be less work to implement them as separate Views. It is all about striking a balance between DRY and KISS.
There are a lot of judgment calls. If you don't feel comfortable making these judgments, I suggest you find another site that is similar to yours and see how they have broken down their views. It is usually pretty easy to tell by paying attention to the URL as you click through the UX.
Basically i am working on UI automation testing of a windows based application using visual studio CODE UI, problem comes as and when the layout changes or some new control is added in the GUI,and the control ID of the controls change.As we can see from the screenshot that a typical hierarchy is recoreded by CODE UI builder which is :-
Main Window ->Window with Control Id property -> Actual control.
So here are my questions related to this heirarchy and control Ids?
1) How are these Control IDs generated?
a) I know there is some logic by which these control ID Nos are
generated, depending on the depth of the control in the GUI,but i am
not able to find out any consistent way of how they are generated ,
for example in images the two buttons connect and help seems to be
in same level of GUI but still their control IDs are so different 1
and 5013.
b) Are these control IDs generated by coded UI builder used in Testing
environment or there is some logic in product development side or that code itself
by which they are generated
2)Is there a way to skip this middle layer of window with control ID and do the record and playback successfully.(As in my case we have access to logical name of all the controls which themselves are unique in nature ,and we are good to get rid of these control IDs)
3)Plus Can we have hybrid approach where we have two layers for almost all controls but three layers for some special cases where its not possible to work with logical name or label only and we explicitly require control IDs
4)Last but not least how much of the accessibily implementation of this type can be done in Testing Environment as per my knowledge most part of accessibilty of controls has to be done on the product development Environment by adding some properties in code itself which then can be retrived for testing using various tools like CODE UI in testing Environment.
But for large scale products i dont think that is a good approach as it imposes extra burden on development side and it is like adding extra unnecessary code in product(needed for testing purposes only) which needs to be delivered to the customer.
Plz see images below as a reference for clarity on my questions.
1st Image shows Remote Desktop GUI
2nd shows Computer: control properties recorded by CODED UI
3rd shows Connect Button properties recorded by CODED UI
4th shows Help Button properties recorded by CODED UI
I am only starting with CodedUI now, but I did a lot of UI Automation using different products before and using the same technology (MSUIA etc.). So this should apply here as well.
Each control has several properties, like name and automationid to name the most important ones. If you are automating a UI that is your own (you code/build it yourself) you should always attempt to give a unique automationid to each control, that will make your life a lot easier when automating. Name often is a bad option, since it frequently changes when you have a different language version of a program.
Since in that case you do not have the source and cannot influence the values it reports, you have to work with what is given. Still, even though CodedUI recorder will choose any property it sees fit, you can change the search criteria yourself by changing the UIMap.uitest for each element found:
This probably will take some time getting used to.. especially for more complicated UIs where elements have similar properties, also for dynamic UIs, etc.
By the way, the products I was using earlier on directly were working with AutomationElements, and here you have the full power to select and do what you want - even though with a high maintenance and start cost. (Ok, so it is generally very time consuming - and will always be more time consuming than using any ready solution like VS Coded UI.)
One more easy solution also is to simply go by coordinates (relative to some known controls, like main window or a tab group), this also will work 99% of the time and bring you to your goal that much quicker.
Ok, answering your concrete questions
1) if that is what I think it is, they are generated at runtime and there really is no relying on them
2) When going lower level (like AutomationElement) you can search whole trees. Still, that will typically make the search rather slow as well - not much faster then if you get the whole tree yourself and traverse it
3) You can mix anything you want. Actually, you can even convert handles to AutomationElements to Controls (at least for most standard controls). So you could use any technology, like Win32 SDK, to traverse the tree. Actually, all GUI trees in all technologies are similar - though not the same. And few people coding seem to adhere to any standards.. at least that is my experience.
4) Using a variation of technologies, coordinates (actually, I even used screenshots) etc you can achieve almost everything. It takes a lot a lot of time though. Getting the basics right during development and taking feedback from UI test developers into account can greatly help speed up later testing.
Simplest example: whether an application paints "all ok" on the screen or whether there is a control that can reach that has a name property that says "all ok" - second solution will be a lot better for the automation guy.
Also, for more complicated UIs, if you are in a corporate environment, have some money and want to spend a lot of time on UI tests anyway, I suggest a product like Ranorex, SilkRunner and the like. I worked with a Ranorex Eval for a few days and (after some getting used to it) could navigate UIs that very rather difficult to navigate myself beforehand.
I've got a C# form, with various controls on it. The form controls an ongoing process, and there are many, many aspects that need to be right for the program to run correctly.
Each part can be unit tested (for instance, loading some coefficients, drawing some diagnostics) but I often run into problems that are best described with an example:
"If I click here, then here, then change this, then re-open the form, then click here, it crashes or produces an error"
I've tried my best to use common code organisational ideas (inheritance, DRY, separation of concerns) but there never seems to be a way to test every single path, and inevitably, a form with several controls will have a huge number of ways to execute.
What can I read (preferably online) that addresses this kind of issue, and is there a (non-generic) term for it. This isn't a specific problem I'm having, but one that creeps up on me, especially with WinForms.
You're trying to do acceptance testing, not unit. It is useful to test whether all bricks of your system are properly connected together. But bricks themselves should be tested with unit-tests.
So if you have a functionality that takes some coefficients and makes diagram, test it separately from GUI from all sides. Give it all possible edge-cases of coefficients and test point coordinates it returns. It was just one unit, there will be dozens, hundreds or thousands.
After you're sure in your units, do few functional/integrational/acceptance tests to make sure your units play well together.
For unit testing you can use NUnit or built-in test system.
For acceptance testing look at FITnesse or search for commercial products.
And to get an idea of how to divide the application in units, read about MVC and similar architecture solutions.
Each of those principles (inheritance, DRY, separation of concerns) is not a guaranteed recipe for high quality code, of course. If you use your inherited and DRY method to divide by zero, then you're still doing something wrong.
My advice for hard-to-trace errors: logging! Log the internal state of variables at key points in the user's steps to reproduce the problem.
I'd try and map common user UI workflows (with slight deviations, perhaps using "foreach" on control lists to pretend you're a user spamming everywhere and changing stuff) as unit tests.
I wouldn't go as far as (click at (x,y)) but more firing events like "txtUsername_Focused", "txtUsername_TextChanged", "btnBack_Click", "btnForward_Click", "btnSave_Submit", of course with some handling if you get different forms showing as a result.
I have faced this problem (test every single path) with Windows Forms. But after moving to WPF,Silverlight the problem is solved. Use MVVM along with command pattern (basically ensuring that you have no code in code-behind files). Ensure that you have single responsibility classes. In your unit tests, you can simulate every scenario including button clicks and you will be able to test all possible paths.
I am not sure how you will be able to use MVVM and command pattern in WinForms. But, I am google will definitely provide you with some answers.
I am trying to determine that if (before I start) on a new project I can pick some suitable patterns which will help with development as the project gets more complicated.
The Scenario
To have an application that draws 'simple' lines on the screen. Ideally encompassed into a 'Render Engine' which I can package into Silverlight, WPF demo applications etc.
I also require editor application that uses the render engine to do the bulk of the displaying, however provides additional functionality like control points for moving the lines about the screen & Dialogs for changing the colours of the lines etc.
The Goal
To keep the render engine specalised and efficient. The editor should be able to 'inject' the additional functionality (i.e. display of control points) into the objects used by the rendering engine, or into the render engine itself. I don't want to code any editor specific code into the render engine.
My thoughts so far
I'm thinking of using an encapsulation/template pattern for the objects that will be used by the rendering engine, somehow allowing the editor application to supply a class to the object which 'tacks on' the functionality for the control points (and for example the event handling for moving of the control points).
My reason behind liking this idea is that the rendering engine never need know about the environment in which it is working. The editor can be changed extensively without ever having to change the rendering engine (hopefully).
But....
I may be wrong, if anyone can see any pitfalls, or has experience of better ways to tackling this problem I would love to hear them!
I agree with Charlie that you should start with a simple design prototype and extend it as needed (that's how I started with my map rendering engine). I can give you a few suggestions though:
Separate the drawing engine from the rest of the code (here's an example how). By the drawing engine I mean the code that actually draws something on the screen/bitmap. It should consume drawing primitives, not some higher-level entities. This way you'll be able to switch the drawing engine easily (example: SVG, PDF, GDI, WPF...)
If you want to have an editor, one of the patterns that are useful is the State pattern
Well shoot, that's an impressive amount of forethought.
My philosophy has always been, use a design pattern when you need to use one. Otherwise you may become an architecture astronaut, designing grand schemes all for naught. It's good that you're thinking about design before development, but really, how much can you possibly know about the project before any code has been written? Just about nothing. And if you force yourself into a pattern before any code has been written, you may end up jamming a square peg into a round hole for the entire lifecycle of the application.
My advice to you: write a prototype first. Quick and dirty. No real design; just make a skeleton that walks. Learn from it. If you thought of a better way, scrap the original and redesign a new one. Use design patterns that make sense as you add functionality, not for the sake of adding functionality.
Is there a pattern where in WPF, I can build a simple UI form from an XML like definition file pulled from a database?
It would allow the user to enter data into this form, and submit it back. The data would be sent back in an XML structure that would closely/exactly mimic the UI definition.
The definition should include the data-type, and if it was a required value or not. I would then like to map these data-types and required values to Data Validation Rules, so the form could not be submitted unless it passes the check.
It should also handle the ability to have lists of repeating data.
I am in the planning stages of this project and have fairly good flexibility in the design at this point, though I am pretty sure I need to stick to the desktop, not web since I may be doing some Office Inter-op stuff as well.
What technology stack would you recommend? I think XMAL and WPF may be close to the answer.
I have also looked at XUL, but it doesn't seem ready or useful for C#. (Found this article from MSDN in 2002)
Thank you,
Keith
Model View Presenter seems to suit WPF quite well, if you've not heard of it before check out the Supervisor Controller pattern, which is a subset of MVP (the author has renamed it to Supervisor Controller and Passive View as two different flavours of MVP). It is a design principal that will help you promote the separation of concerns and works much better than MVC when you don't have a framework to physically enforce it.
You could always try to create a view engine for ASP.NET MVC that works with WPF though, that would be nice.
Well if you wanted to roll something yourself, you can load and render dynamic XAML pretty easily. Rather than have users create XAML directly you could have a subset of it "mapped" to an XML format of your choosing that you XSL into valid XAML:
XmlReader tXml = XmlReader.Create(myXamlString);
UIElement MyElement = (UIElement)XamlReader.Load(tXml);
What about Caliburn?
You might want to consider taking a look at the CSLA.NET framework. You can read about it here along with info on a well written book that's available:
http://www.lhotka.net/Default.aspx
-Eric