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
Ok, this subject is probably done to death but I wanted to throw it out there to see what people thought of my approach.
I need to create a simple WinForms application that will consist of a handle of forms. There will be variables that I can stick into the app.config as they'll never really change. However there will be some variables that are pulled in from a database unique to the user thats logging in. It's these variables that I need to persist and make available to the rest of the application to drive appropriate business logic.
Based on other articles on StackOverflow my plan would be to use the singleton pattern with IoC. So first instantiating a class based on the singleton pattern which is hooked up to an interface. The instantiated object would then be passed into the constructer of other methods in program.cs where I'll arrange most of my objects. This should mean I can easily test and mock this and other classes (I think?).
I've seen there are two ways of creating a class based on the singleton pattern, one that is the 'classic' way of doing it but isn't thread safe. The other requires slightly more coding but would be thread safe. My WinForms project would be pretty simplistic and wouldn't require multiple operations running in the background. Just simple CRUD operations fired off from the UI. For ease, I thought I'd use the classic singleton (non-thread safe) approach. That said, is that a bad thing to do, even for the most simplest of WinForm apps?
If you're using .NET 4.0+, just use Lazy<T> class for your singletons. If you insist on not caring about thread safety (why though?), get => _value ?? (_value = GetValue()) is enough.
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
I am developing a software in WPF c#. My software has multiple windows. I need to share a same instance of on object across multiple windows (I am using legacy code, so I can not make that object static). Is it a good practice to have a static class which will have variables that I need to share across multiple windows, so I can avoid passing them through a constructor. Thank you
You could either use a static class or you could inject all windows/view models with the same singleton instance. Note that this doesn't necessarily has to be a class that actually implements the singleton design pattern but you need to make sure that you inject the windows/view models with the very same instance.
The latter approach is the preferred one, mainly because a non-static shared class can implement an interface which enables you to easily replace the implementation with another one which in turn makes it a lot easier to unit test your classes.
So it is not, at least in the general case, really a good practice to use a global static class but this might still work in your specific scenario.
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 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 7 years ago.
Improve this question
If I've some common functionality that I've to keep in a class, so will I go for static, sealed or abstract class...Does all these types of classes serve the purpose of keeping the common functionality together...where actually the difference lies when I've to go for one
abstract, sealed, static has nothing to do with real time development. It has to do with bring structure within your software, so that the functionality implemented in classes can and should be used in the right way.
After some comments i think this:
I think you can only learn this, by doing it. There isn't a book or epub that will explain you how to do programming. They will show the syntax and some examples. It will be trial and error. Every day you'll face a new challenge.
You'll have to practice it. The best advise is, look what others already created and try to imagine why did they wrote/solve it that way.
I can explain what a static/sealed/abstract class is/does, but it doesn't learn you when to use it.
Back to the question: Define 'real time'.. I think that static/abstract/sealed should NOT be decisive on how you write your 'real-time' software. If you are 'scared' about performance on this level, C# should not be your choise. I would write c++ or if you want a real challenge, try to beat the compilers with asm ;-)
I think you won't measure the 'overhead'
So, use abstract/static/sealed in a right way, so your future collega's/you can read/maintain it.
I use C# for communication (tcp/ip) between a windows computer and a PLC (with delta robots). But it's far from realtime. It's fast enough to keep many robot working with > 100 messages per second.
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 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.
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
This might be a bit vague, but I am working on a program where several classes that update the UI. I have made a "middle-man" class that basically takes all the UI requests (among other things) and routes them to the UI itself, that way the UI class only interacts with the middle-man.
The problem is that the UI class has ~20 different functions in its interface, and all my middle-man class does is basically take calls from the lower-level classes and then call an essentially identical function in the UI, which makes me wonder if this is somehow defeating the whole purpose. I'm sure this is a problem that comes up a lot. Is there any more elegant way to do this?
Thanks,
PM
It's nice to not have to refer to UI stuff in the backend. I assume this is the reason you're wanting to do this.
If that's the case, what you could do is implement some Publish/subscribe pattern (such as the Observer pattern). That way, you don't have to refer specifically to the UI. You can just "publish" from your backend, and subscribe to those events from your UI.
Alternatively, you could inherit your UI from an interface, and specify the methods you need on that. Then, refer only to the interface in your backend.
Unfortunately you don't really state what you are using to build your UI. But the whole problem can quickly disappear with WPF (or Silverlight) and data binding. In a nutshell items in the UI are bound to properties and commands in a backing class. When a property changes the PropertyChanged event is raised and the UI knows to update itself. For more information start searching on MVVM.
At the end of the day, this is actually a form of the observer pattern, but you don't have to do all the wiring yourself.