In my LINQ generate class, I have this method:
[global::System.Data.Linq.Mapping.ColumnAttribute(Storage="_Id",
AutoSync=AutoSync.OnInsert, DbType="Int NOT NULL IDENTITY",
IsPrimaryKey=true, IsDbGenerated=true)]
public int Id
{
get
{
return this._Id;
}
set
{
if ((this._Id != value))
{
this.OnIdChanging(value);
this.SendPropertyChanging();
this._Id = value;
this.SendPropertyChanged("Id");
this.OnIdChanged();
}
}
}
In my coded partial class, I extend from a base class. The base class defines:
public virtual int Id { get; set; }
The concept is that I can add the Equals and Hashcode at the base class level, as well as some other functionality at the base class level. The problem is that the generated classes (from LINQ-to-SQL) do not get an override keyword so it doesnt work. If it had override I would be all set.
Please suggest on how to complete this.
You could make the base class abstract, and then the Id property becomes
public abstract int Id { get; set; }
The generated code will implement that abstract property.
A partial class is different from overriding a class. With a partial class you're just saying. Ok, i have 1 class but i have splitted the source up over multiple files (mainly for maintainable reasons like splitting the auto generated code from your own code). The C# compiler just merges each part of a partial class together and threats it as 1 class. Ofcourse overriding a class means you create a new class which takes on the characteristics of the base class. That is very different.
Now it's possible but not relatively easy to direct EF of how to generate your code (assuming you are using EF). One option you can do though is to change your base class not to work with the Property Id but a more recognizable (and specifix?) name like 'CompareIdentifier'. With that you can override CompareIdentifier in your derived class for returning the auto generated ID. And ofcourse do all comparison work against CompareIdentifier
I would have created a wrapper class around this.
Related
Using this abstract class:
#JsonTypeInfo(use = Id.NAME, include = As.PROPERTY, property = "type")
#JsonSubTypes({ #JsonSubTypes.Type(value = PostingTaskInstanceDto.class, name = "TI") })
public abstract class BasePostingDto {}
and this inherited class:
public class PostingTaskInstanceDto extends BasePostingDto {}
I get correct serialization for a single object. This works, using Spring-MVC:
#RequestMapping("/{id}")
#ResponseBody
public BasePostingDto findById(#PathVariable("id") Long id) {
return createDto(postingService.findById(id));
}
But if I retrieve a List of BasePostingDto from the remote controller, the type property is missing:
#RequestMapping("/by-user/all")
#ResponseBody
public List<BasePostingDto> findByUser() {
return createDtoList(postingService.findByUser(AuthUtils.getUser()));
}
Why is this and how can I force the type property?
Update: the type property is also included if I change List<BasePostingDto> to BasePostingDto[], however I would prefer to go with the List.
It sounds like the framework you are using (and which uses Jackson under the hood) is not passing full generics-aware type information.
I don't know how that can be fixed (it is problem with integration by framework, and not something Jackson can address), but the usual work around is for you to use sub-class of List:
public class PostingDtoList extends List<BasePostingDto> { }
and use that in signature, instead of generic type. This solves the issue because then the generic type signature is retained (since it is stored in super type declaration, and accessible via type-erased PostingDtoList class!).
In generally I think it is best to avoid using generic List and Map types as root type (and instead use POJO); partly because of problems issued (there are bigger problems when using XML for example). But it can be made to work if need be.
say, Child class is inheriting Father class and Father class is inheriting spark TextArea class. now from an mxml file (in FLEX4), i am creating multiple objects of Child class. Father class have few static attributes whose values are set by private methods, calling from constructor. Now the question is: all these static attributes are set every time while Child class objects are being created one by one?
If answer is yes then Is it possible that Father class static attributes are set only once and not depends upon the number of Child class objects creation.
Please provide any suggestion or tips
Thanks in advance.
If you are setting static variables from an object's constructor or methods called from the constructor, then yes, they will be set every time. In order to prevent that, just check whether the variable is already set.
public class Foo {
public static var bar:Object;
public Foo(value:Object) {
if (!bar) {
bar = value;
}
}
}
First decide if those static members are really all that important to store as statics because statics are associated with a Class and not an instance it's usually a signal that you're probably doing something you shouldn't if instances are modifying or reading static members. You probably should use a factory method if you need to share that information with the instances. However, if you're sure you should do it then you can use a static initializer block to initialize the members when the class is loaded. Downside is that block throws an exception it can be hard to track down:
public class SomeObject {
private const _someStaticMember : String;
private const _someOtherStaticMember : SomeOtherObject;
static {
_someStaticMember = "foobar";
_someOtherStaticMember = new SomeOtherObject();
}
}
I am trying to find a way so that I can push some common functionality into a base class for my Linq to SQL processing. I have two fields (ID and InsertUpdateOperID) that are common to most but not all of my tables. In my first go around I created a class called BaseEntity that had these fields. Unfortunately all I accomplished was hiding from the values in the .designer.cs file. I found an example of how to accomplish what I wanted In order to get around this (http://www.joe-stevens.com/2009/07/01/linq-to-sql-set-inheritance-modifiers-with-sqlmetal/). As per this article, I modifed the DBML file so that I could add the override modifier to the ID and InsertUpdateOperID properties on the tables that contained these two fields.
The net result of this was that the .designer.cs file added the override qualifier where I wanted it. This enabled me to create my BaseEntity class. Where I defined the ID field and the InsertUpdateOperID field as:
public virtual int ID { get; set; }
public virtual int InsertUpdateOperID { get; set; }
Doing this seemed to work fine.
The problem for me is that I hate the idea of modifying generated code. Can anyone suggest a way for me to put common fields and methods that act on those common fields in a base class so that I could accomplish what I want without modifying the generated .dbml?
Thanks
I'm facing the same problem today (wow, it's 1.5 years after your post), and struggled out a solution, so far it's good for me.
in the base class:
public virtual int __ID
{
get
{
PropertyInfo pi = this.GetType().GetProperty("ID");
int id = (int)pi.GetValue(this, new object[] {});
return id;
}
set
{
PropertyInfo pi = this.GetType().GetProperty("ID");
pi.SetValue(this, value, new object[] { });
}
}
This looks quite voilent, but it works!
Notice the __ before ID, because there is alread ID and _ID in the auto generated codes. As it's totally a new third way to access ID, no "override" is needed.
And if you need, you can use the __ID in or via your base class.
My datacontext contains a table named Userlog with a one to many relationship with table UserProfile.
In class UserLog
public UserProfile UserProfile
{
get {return this._UserProfile.Entity;}
}
In class UserProfile
public EntitySet<UserLog> UserLogs
{
get{return this._UserLogs;}
}
{
set {this._UserLogs.Assign(value);
}
How would I go about mocking (using Moq) UserLog.UserProfile without changing the autogenerated code?
What I would like to do is something like:
var mockUserLog = new Mock<UserLog>();
mockUserLog.Setup(c=>c.UserProfile.FirstName).Returns("Fred");
etc
I can do this if I go into the designer.cs and make FirstName and UserProfile virtual, however I would like to do this in the partial class.
Any ideas?
Thanks
Jeremy
The reason you need to make the method virtual is because you are mocking a direct class. Best way to approach this is to make a partial class (like you suggested) and let that partial class inheret an interface. So you will have something like:
designer.cs -> public partial class UserLog
UserLog.cs -> public partial class UserLog : IUserLog
IUserLog.cs -> methods that should be implemented (methods will be implemented by the designer.cs)
The partial class you create (UserLog.cs) is only there to make it possible to implement IUserLog. IUserLog will then contain all the methods that need to be implemented, like: public UserProfile UserProfile().
Once you've done that you can mock the interface instead of the class.
I hope this helped, it might be more difficult then I explained though.
I'm working through the book Head First C# (and it's going well so far), but I'm having a lot of trouble wrapping my head around the syntax involved with using the "this." keyword.
Conceptually, I get that I'm supposed to use it to avoid having a parameter mask a field of the same name, but I'm having trouble actually tracking it through their examples (also, they don't seem to have a section dedicated to that particular keyword, they just explain it and start using it in their examples).
Does anyone have any good rules of thumb they follow when applying "this."? Or any tutorials online that explain it in a different way that Head First C#?
Thanks!
Personally I only use it when I have to which is:
Constructor chaining:
public Foo(int x) : this(x, null)
{
}
public Foo(int x, string name)
{
...
}
Copying from a parameter name into a field (not as common in C# as in Java, as you'd usually use a property - but common in constructors)
public void SetName(string name)
{
// Just "name = name" would be no-op; within this method,
// "name" refers to the parameter, not the field
this.name = name;
}
Referring to this object without any members involved:
Console.WriteLine(this);
Declaring an extension method:
public static TimeSpan Days(this int days)
{
return TimeSpan.FromDays(days);
}
Some other people always use it (e.g. for other method calls) - personally I find that clutters things up a bit.
StyleCop's default coding style enforces the following rule:
A1101: The call to {method or property
name} must begin with the 'this.'
prefix to indicate that the item is a
member of the class.
Which means that every method, field, property that belongs to the current class will be prefixed by this. I was initially resistant to this rule, which makes your code more verbose, but it has grown on me since, as it makes the code pretty clear. This thread discusses the question.
I write this. if and only if it enhances readability, for example, when implementing a Comparable interface (Java, but the idea is the same):
public void compareTo(MyClass other) {
if (this.someField > other.someField) return 1;
if (this.someField < other.someField) return -1;
return 0;
}
As to parameter shadowing (e.g. in constructors): I usually give those a shorter name of the corresponding field, such as:
class Rect {
private int width, height;
public Rect(int w, int h) {
width = w;
height = h;
}
}
Basically, this gives you a reference to the current object. You can use it to access members on the object, or to pass the current object as parameters into other methods.
It is entirely unnecessary in almost all cases to place it before accessing member variables or method calls, although some style guidelines recommend it for various reasons.
Personally, I make sure I name my member variables to be clearly different from my parameters to avoid ever having to use 'this.'. For example:
private String _someData;
public String SomeData
{
get{return _someData;}
set{_someData = value;}
}
It's very much an individual preference though, and some people will recommend that you name the property and member variable the same (just case difference - 'someData' and 'SomeData') and use the this keyword when accessing the private member to indicate the difference.
So as for a rule of thumb - Avoid using it. If you find yourself using it to distinguish between local/parameters variables and member variables then rename one of them so you don't have to use 'this'.
The cases where I would use it are multiple constructors, passing a reference to other methods and in extension methods. (See Jon's answer for examples)
If you have a method inside a class which uses same class's fields, you can use this.
public class FullName
{
public string fn { set; get; }
public string sn { set; get; }
//overriding Equals method
public override bool Equals(object obj)
{
if (!(obj is FullName))
return false;
if (obj == null)
return false;
return this.fn == ((FullName)obj).fn &&
this.sn == ((FullName)obj).sn;
}
//overriding GetHashCode
public override int GetHashCode()
{
return this.fn.GetHashCode() ^ this.sn.GetHashCode();
}
}