I've got this
public static class MyClassHelper
{
DataContex db = new DataContext();
public static Type MyMethod()
{
//Do Something with db
// such as db.myTable
}
}
I'm getting the following error: "An object reference is required for the non-static field, method or property..."
Is there anyway to get around this?
How about this. I've an object that contains only integers, which is fine for all the internal functionings as it allows me to link tables. But occasionaly, I need to display some information to the user. That's why, I'd like to create a static method so it would read the integer, look up in the DB, and display a name instead of a number.
I want it to be a static method so that I can use it in my View template.
Thanks for helping
As #Oskar indicates your static method can't reference instance variables, only static variables. Rather than making the DataContext static, though, which would mean that it would exist for the life of the program, just create the DataContext as needed within the method. DataContext are best suited to a "unit of work" pattern and recreated as needed for just the task being accomplished rather than existing as a long-lived object. Be aware, too, that the DataContext is not thread-safe; you'll be creating some really hard to find errors unless you make all of your methods thread-safe. It's much simpler to just recreate the data context.
A static method can only see static members. Also, a static class can only have static member. You should mark your db as static:
static DataContext db = new DataContext();
Yep. You need to declare your DataContext to be static as well.
Related
Alright so I've been continuing to learn about classes and oop languages. And am a bit confused.
If I was to have a separate class for player stats. And in that class I have some private ints and then some functions to change them publicly.
Say I want to change and get those ints From my main class. I make an object and assign them to local variables then I can call the local variables in my main script. Then update the variable in the stat class.
It seems a little silly that I have to make a local variable as well as a separate variable in a different class.
To me it would make sense to just be able to call the separate class in a new object whenever I wanted to access the variables in the stat class but I can't...
Let me know if this isn't clear as I can try to expand more.
Thanks
Ben
You do not have to make new variables in the "main" class ....
you can just use the getters and setters through the object that you created.
Also copying variables from player stats to main class is not a good idea because now you have to maintain two copies of same data, at least until you are in scope of main class. If not handled correctly it can also cause data inconsistencies.
Assuming you are using Java, you can do this.
public class PlayerStats{
private int var1=20;
public void setVar1(int var1){
this.var1=var1
}
public int getVar1(){
return var1
}
}
public class mainClass{
PlayerStats pStats = new PlayerStats();
pStats.getVar1();
pStats.setVar1(14);
System.out.println(pStats.getVar1());
}
Thanks for that answer definately cleared things up however, in the object created in mainClass if I create the object in one function how do I use it in another function in the same class?
Depends on how and if the two functions are connected and how central that object is to your class.
If the object is very central to class :
That is, you are using it almost in all the function, your class revolves around playing with that object, then you can create it at class level something along these lines
public class mainClass{
PlayerStats pStats = new PlayerStats();
public void function1() {
pStats.setVar1(14);
System.out.println(pStats.getVar1());
}
public void function2(int x) {
pStats.setVar1(x);
System.out.println(pStats.getVar1());
}
}
If two functions are not connected :
Just make a new object inside the function scope, if possible.
This is better than creating an object at class level, because the object becomes eligible for garbage collection after the function is finished executing. Whereas, the object created at class level stays in the memory as long as the object (instance of main class) is in the memory.
If two functions are connected, i.e you are calling one function from inside the second function :
you can just pass the object as an argument, something along these lines
public class mainClass{
public void function1() {
PlayerStats pStats = new PlayerStats();
pStats.setVar1(14);
function2(pStats)
}
public void function2(PlayerStats x) {
System.out.println(pStats.getVar1());
}
}
Also google dependency injection, it is an important concept, try to use it as often as possible. It produces good decoupled and testable design
There is so much more to say, people have written books on this topic, OO Design is an art in itself.
I am using version 4 of MVVM Light for Windows 8; it includes SimpleIOC. In various examples I sometimes see code to request an object based on SimpleIoc... and sometimes it is based on ServiceLocator...
Examples include:
userToken = SimpleIoc.Default.GetInstance();
mainVM = ServiceLocator.Current.GetInstance();
What is the difference between using SimpleIoc.Default.GetInstance and ServiceLocator.Current.GetInstance?
If there is no difference, does ServiceLocator just let me to have an option to change my mind about what IOC library I want to use? Does ServiceLocator just provide an additional layer of abstraction that is irrelevant if I am satified with SimpleIoc; or, does ServiceLocator perform some other useful magic that is not obvious to we IOC novices?
Thanks for the insight!
In your ViewModelLocator class you probably have the following line of code:
public ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
SimpleIoc implements the IServiceLocator interface, which means that the ServiceLocator will use it as a DI source when invoked.
Edit:
OK, people want the "full fat and don't spare the cream" answer. Here we go!
ServiceLocator is basically a shell. The code for Service locator is:
public static class ServiceLocator
{
private static ServiceLocatorProvider currentProvider;
public static IServiceLocator Current
{
get
{
return ServiceLocator.currentProvider();
}
}
public static void SetLocatorProvider(ServiceLocatorProvider newProvider)
{
ServiceLocator.currentProvider = newProvider;
}
}
Yup, that's it.
What's ServiceLocatorProvider? It's a delegate that returns an object that implements IServiceLocator.
SimpleIoc Implements IServiceLocator. So when we do:
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
We put our SimpleIoc object into the ServiceLocator. You can use either of these now because whether you call ServiceLocator.Current or SimpleIoc.Default you're returning the same object instance.
So, is there any difference between
userToken = SimpleIoc.Default.GetInstance();
mainVM = ServiceLocator.Current.GetInstance();
?
Nope. None. Both are singletons exposing a static property that is an implementation of IServiceLocator. As mentioned above, you're returning the same instance of object that implements IServiceLocator regardless of which you call.
The only reason why you might want to user ServiceLocator.Current.GetInstance() rather than SimpleIoc.Default.GetInstance() is that at some point in the future you may change DI containers and, if you use ServiceLocator, you won't have to change your code.
Based on Mr. Bugnion's article on MSDN (in the section, "Various Ways to Register a Class"), I am presuming interchangeability of IoC providers is the one and only reason for using ServiceLocator.
As #FasterSolutions stated, SimpleIoc implements IServiceLocator, so I suspect the opposite to your statement about abstraction layers is true. I think you should use ServiceLocator, but this is without empirical evidence; maybe someone can prove me wrong (?)
I would like to know what are drawbacks of a stateless class (if any)?
Has anyone seen a real-world application where some use case mandated the creation of a stateless class (No hello world please )?
I think a stateless class means a class without any fields.
Here's a real world example:
Writing plugins for Microsoft Dynamics CRM.
In that doc you'll see a note that says: "The plug-in's Execute method should be written to be stateless".
And basically what it means to be a stateless class is that there should be no global variables (except for a few special cases, which I won't get into unless asked).
The reason why this is mandated by CRM upon plugin developers is because CRM tries to improve performance by caching and re-using instances of plugin classes.
The way CRM executes its plugins is something roughly like this:
Main thread:
YourCustomPlugin yourCustomPluginCached = new YourCustomPlugin();
then later:
Thread1:
yourCustomPluginCached.Execute(context1);
and Thread2:
yourCustomPluginCached.Execute(context2);
What some developers do wrong is they will create a global variable to store the Context, which they set as the first line in the Execute() method. That way they don't have to pass it between all their methods. But this is actually a huge mistake.
Because if they do that, and in the scenario above, if the execution in thread2 begins before the execution from thread1 finishes. That would mean that context1 in thread1 would be overwritten with context2. And now that plugin will have some unexpected result. In 99% of cases, even when developed incorrectly this way, there are no problems, or no noticeable problems. But in 1% of cases, it will cause something to go wrong, and that something will be incredibly difficult for the dev to figure out what went wrong, and will probably never occur when they are testing/debugging. So it will probably go unfixed for a long time.
I never heard "stateless class", but I think you mean immutable objects (very useful notion!).
Or maybe a class which doesn't have any fields, so usually it looks like just bunch of pure functions.
If by stateless class you mean a class of immutable objects, then the drawback is that mutating operations need to copy an object instead of changing it in-place. That might be expensive.
I use these things quite often, pretty much whenever an object's behavior is determined by some input that can be processed all at once. A recent example is a statistical language model that I implemented: the model parameters were determined entirely in the constructor based on training input, and then the model could be queried for probability estimates on unseen text, but not modified. Immutability wasn't strictly mandated, but modifying the object didn't make sense, since there was no need to add data later on (in which case much of the computation had to be redone anyway).
I too am not sure what you mean by that term, but I assume it to mean a class with no fields, as the state of an object is actually the content of its fields.
Now, usually you'd use this kind of class as a collection of related functions - say, a certain Utils class. The common way to use this kind of class is by making its method static, so you don't actually have to create an instance of the class.
The only reason I can think of to actually create such a stateless object is if you'd like the actual functionality to be determined at run-time. So, if you have a UtilsBase class which offers a bunch of virtual methods and a UtilsDerived which overrides some of the methods, you can pass whoever needs to use the utils a reference to UtilsBase, and create the actual utils object at run-time, according to the specific needs.
A bit late, but here is my share.
I am sure the poster meant a stateless object. Please, people don't make it so dramatic.
Let's get to business. Some commenters asked about static. When static is used in a class, which should be used sparingly, all those members holding the static keyword now belong to the class and not anymore to the object. They are part of the class.
For example:
Declaring a Person class with a static property called Name does not make sense
public class Person
{
public **static** string Name { get; set; }
}
by the way another word for static is "Shared" which is used in VB.NET.
If we once set the name on the Person, then that name is shared everywhere because it does not belong to the object, but to the class itself. In real world you would not call all people "Jhon", or all your customers "Customer1". Each one will have a different name, surname, phone, address, etc. The moment we set these properties, this object becomes stateful, instead of stateless. It has a name, an address, etc. The properties of an object defined in a class make it stateful.
Here Name property belongs to the class, not part of the object:
Person.Name="Fili" //You would not call every person Fili in your application.
Let's redeclare the Person class by removing the static keyword:
public class Person
{
public string Name { get; set; }
}
In the example below, the object is stateful. It has a state, it has been given a name, "Jhon", which can be changed later. A person can change his name to Jimmy, for example. Once that is done, then the state of that object has changed from Jhon to Jimmy.
//From
Person person1 = new Person {
Name = "Jhon";
}
//to
person1.Name = "Jimmy"
The object 'person1' still is the same object, but its state has changed. It is not the same anymore. It has a different name.
So, person1 had a state until a cetain point in time, but then its state was changed. Now, it is in a different state.
Now, creating a new person is something new which has nothing to do with the person1. Person2 has its own state.
Person person2 = new Person {
Name = "Imir";
}
Using the static class: Person.Name="Fili" it has a state, but it belongs to the class and it is shared everywhere.
So, a stateless object will be one that has nothing to be changed, doesn't hold a value. Will you create a person without a Name? Would you create a customer object which does not exist? No, of course not. The moment you name a person or a customer, they have a state. They exists and can change their state.
Take the example of a Airplane. When you delcare it you add a Status property for example.
public class Airplane {
public string Status {get;set;}
}
var plane1 = new Airplane{ Status="Flying"};
So, the question arises: what is the state (status) of the plane at this moment?
One would reply: it is "flying". If you change the state to "taxing", then its state is "taxing", or it is "stationary", etc.
In stateless class, all field members should be readonly type. Although c# don't have any such features which will check statelessness at compile time like:
public readonly class MyReadonlyClass
{
public readonly double X {get;set;}
public readonly double Y {get;set;}
public readonly double Z {get;set;}
public MyReadonlyClass(double x_,double y_,double z_)
{
X=x_;Y=y_;Z=z_;
}
}
public readonly static class MyStaticReadonlyClass
{
public readonly static double X {get;set;}
public readonly static double Y {get;set;}
public readonly static double Z {get;set;}
static MyStaticReadonlyClass(double x_,double y_,double z_)
{
X=x_;Y=y_;Z=z_;
}
}
Stateless is something which should not preserve its state or in other words we can say that every time we use the any functionality or member of that class then previously used/set variables should not affect the next use of that class/functionality.
Consider the following code snippet (Ignore the standards)-
class Maths {
int radius;
public void setRadius(int r) {
this.radius = r;
}
public float getCircleArea() {
return (float) (3.14 * radius * radius);
}
}
public class Geometry {
public static void main(String[] args) {
Maths m = new Maths();
m.setRadius(14);
System.out.println(m.getCircleArea());
}
}
if some other running thread changes the value of radius in class Maths then getCircleArea() would give us different results because the state of the variable 'radius' can be change as it is a global variable. This problem occurs mainly in web application where we use bean containers. Most of the beans are Singleton and only has one copy. If we use global variables then there is a possibility that value of a global variable will change.
To make a stateless class try to use local variable so that the scope of the variable will be limited.
Example of the above getCircleArea() will be.
public float getCircleArea(int radius) {
return (float) (3.14 * radius * radius);
}
I have MVVM Project and I want to share one object( singleton ) from the model between several viewmodel what is the good practice to do that?
Thank you for the help
If the object is needed and does not provide value without it force the interface within the object via Constructor Injection; do not push a concrete type via injection always make use of an interface.
Since you are not making use of an IoC container such as Unity, you will need to create your singleton instance at the startup of your application and then make sure that the given instance is passed in via the given ViewModels constructor as needed.
A better approach would be pushing the singleton instance to a service which can provide the needed behavior and then disregard pushing the singleton into the Model. This would be a more MVVM purist approach and will separate concerns across your Models/ViewModels.
EDIT:
If you were making use of Unity you would define a Lifetime Manager at the time of registration.
// Register a type to have a singleton lifetime without mapping the type
// Uses the container only to implement singleton behavior
myContainer.RegisterType<MySingletonObject>(new ContainerControlledLifetimeManager());
// Following code will return a singleton instance of MySingletonObject
// Container will take over lifetime management of the object
myContainer.Resolve<MySingletonObject>();
Once you do this any attempt to resolve MySingletonObject via the IUnityContainer would resolve to the same instance providing the singleton behavior you so desire across the application. ViewModels themselves should not need to have the same instance returned. The data it needs should be abstracted away via a service as referenced earlier which could potentially behave like a singleton and provide a stateful implementation if needed but the ViewModel should not need to be a singleton. If you find yourself making either a Model or ViewModel a singleton; take a step back and analyze your design.
If you have control over all viewmodels then an easy approach (that I've used personally) is to just put a static variable on the base class of all viewmodels and make that accessible to all inheritors (either protected or even public if its useful outside of the viewmodels).
It's good practice anyway to have a common base class for your viewmodels since it allows you to implement property notification in one place (and other common functionality, like messaging etc.) instead of replicating it in all viewmodels.
Something like this is what I've used in my projects:
public class MyViewModelBase : INotifyPropertyChanged
{
private static MySharedSingleton _sharedObj;
static MyViewModelBase()
{
_sharedObj = new MySharedSingleton(/* initialize it here if needed */);
}
// or public
protected MySharedSingleton SharedObject { get { return _sharedObj; } }
// INotifyPropertyChanged stuff
// ...
}
public class SomeViewModel : MyViewModelBase
{
void SomeMethod()
{
SharedObject.DoStuff();
}
}
If the construction of the shared singleton object is heavy, you can of course use any of the standard techniques for lazy instantiation of it.
I would suggest that you inject the dependency into each view model (either constructor or property injection for example), and always work against abstractions in your view models, so that your dependency can easily be mocked or replaced as required. You then just need to ensure that each view model uses the same instance of your type - if you are using an IoC container, you can register a shared instance of your type easily.
I use a separate class for my global singleton with a model. This relieves me of agonizing over how to inject this model into view models and other models. E.g.
The singleton:
public class ApplicationModel
{
public string LoggedOnUser { get; set; }
// Etc.
private ApplicationModel() {
// Set things up.
}
private static ApplicationModel _active;
public static ApplicationModel Current {
get {
if (_active == null) {
_active = new ApplicationModel();
}
return _active;
}
}
}
The view model that needs to hold no reference to the singleton:
public class SomeViewModel
{
private string _user;
public SomeViewModel() {
_user = ApplicationModel.Current.LoggedOnUser;
}
}
This is pretty basic, but sort of a generic issue so I want to hear what people's thoughts are. I have a situation where I need to take an existing MSI file and update it with a few standard modifications and spit out a new MSI file (duplication of old file with changes).
I started writing this with a few public methods and a basic input path for the original MSI. The thing is, for this to work properly, a strict path of calls has to be followed from the caller:
var custom = CustomPackage(sourcemsipath);
custom.Duplicate(targetmsipath);
custom.Upgrade();
custom.Save();
custom.WriteSmsXmlFile(targetxmlpath);
Would it be better to put all the conversion logic as part of the constructor instead of making them available as public methods? (in order to avoid having the caller have to know what the "proper order" is):
var custom = CustomPackage(sourcemsipath, targetmsipath); // saves converted msi
custom.WriteSmsXmlFile(targetxmlpath); // saves optional xml for sms
The constructor would then directly duplicate the MSI file, upgrade it and save it to the target location. The "WriteSmsXmlFile is still a public method since it is not always required.
Personally I don't like to have the constructor actually "do stuff" - I prefer to be able to call public methods, but it seems wrong to assume that the caller should know the proper order of calls?
An alternative would be to duplicate the file first, and then pass the duplicated file to the constructor - but it seems better to have the class do this on its own.
Maybe I got it all backwards and need two classes instead: SourcePackage, TargetPackage and pass the SourcePackage into the constructor of the TargetPackage?
I'd go with your first thought: put all of the conversion logic into one place. No reason to expose that sequence to users.
Incidentally, I agree with you about not putting actions into a constructor. I'd probably not do this in the constructor, and instead do it in a separate converter method, but that's personal taste.
It may be just me, but the thought of a constructor doing all these things makes me shiver. But why not provide a static method, which does all this:
public class CustomPackage
{
private CustomPackage(String sourcePath)
{
...
}
public static CustomPackage Create(String sourcePath, String targetPath)
{
var custom = CustomPackage(sourcePath);
custom.Duplicate(targetPath);
custom.Upgrade();
custom.Save();
return custom;
}
}
The actual advantage of this method is, that you won't have to give out an instance of CustomPackage unless the conversion process actually succeeded (safe of the optional parts).
Edit In C#, this factory method can even be used (by using delegates) as a "true" factory according to the Factory Pattern:
public interface ICustomizedPackage
{
...
}
public class CustomPackage: ICustomizedPackage
{
...
}
public class Consumer
{
public delegate ICustomizedPackage Factory(String,String);
private Factory factory;
public Consumer(Factory factory)
{
this.factory = factory;
}
private ICustomizedPackage CreatePackage()
{
return factory.Invoke(..., ...);
}
...
}
and later:
new Consumer(CustomPackage.Create);
You're right to think that the constructor shouldn't do any more work than to simply initialize the object.
Sounds to me like what you need is a Convert(targetmsipath) function that wraps the calls to Duplicate, Upgrade and Save, thereby removing the need for the caller to know the correct order of operations, while at the same time keeping the logic out of the constructor.
You can also overload it to include a targetxmlpath parameter that, when supplied, also calls the WriteSmsXmlFile function. That way all the related operations are called from the same function on the caller's side and the order of operations is always correct.
In such situations I typicaly use the following design:
var task = new Task(src, dst); // required params goes to constructor
task.Progress = ProgressHandler; // optional params setup
task.Run();
I think there are service-oriented ways and object-oritented ways.
The service-oriented way would be to create series of filters that passes along an immutable data transfer object (entity).
var service1 = new Msi1Service();
var msi1 = service1.ReadFromFile(sourceMsiPath);
var service2 = new MsiCustomService();
var msi2 = service2.Convert(msi1);
service2.WriteToFile(msi2, targetMsiPath);
service2.WriteSmsXmlFile(msi2, targetXmlPath);
The object-oriented ways can use decorator pattern.
var decoratedMsi = new CustomMsiDecorator(new MsiFile(sourceMsiPath));
decoratedMsi.WriteToFile(targetMsiPath);
decoratedMsi.WriteSmsXmlFile(targetXmlPath);