public class User
{
public long Id {get;set;}
[References(typeof(City))]
public long CityId {get;set;}
[????]
public City {get;set;}
}
I'm trying to use ServiceStack.OrmLite. I'm using both ReferenceKey(CityId) and Reference (City). ReferenceKey is for Db creation, Reference is for using object in my code.
IgnoreAttribute .. Tested, it works.
Try the [IgnoreDataMember] attribute.
This attribute will tell the ServiceStack libraries to ignore this property.
Related
I am passing in a query string that specifies a property to sort on but need to translate that to a property value in a model.
public class A
{
public int Prop1 {get; set;}
public int Prop2 {get; set;}
}
query string segment sort=Prop1
Server Side Code
query is a IQueryable
query.OrderBy(x => x.{properyName})
I have parsed the property name value from the query string but now I need to translate that to x.Prop1 in the orderby lambda not sure a great way without using reflection
In ASP.NET MVC application I have a model named CarSearchCriteria:
public class CarSearchCriteria{
public int CarMake {get;set;} // This is selected from a dropdownlist
public int YearOfFirstReg {get;set;}
public string ModelVariant {get;set}
}
I have two views - one for editing and the other one for viewing. In the editing view for the CarMake property I can do the following. I know I could have used DropDownListFor but didn't want to mess with SelectList for the time being:
<select name="CarMake">
<option value="1">BMW</option>
<option value="2">Mercedes</option>
<option value="3">Toyota</option>
</select>
So the model binding mechanism will easily bind the selected value to the appropriate model property. But what about the reading mode. I can't show 1s or 2s. I need to show BMW, Mercedes and so on. My question is what is the preferred way, do I have to have a property name that holds the actual textual information, something like CarMakeText?
You could have both the identifier (which you currently have) as well as the Make object itself. The latter would never need to be accessed when building the model, but can be accessed when reading the model. A lazy-loaded read-only property often works well for that. Something like this:
public int CarMakeID { get; set; }
public Make CarMake
{
get
{
if (CarMakeID == default(int))
return null;
// fetch the Make from data and return it
}
}
Naturally, this depends a lot on what a Make actually is and where you get it. If there's just some in-memory list somewhere then that should work fine. If fetching an instance of a Make is a little more of an operation (say, fetching from a database) then maybe some in-object caching would be in order in case you need to access it more than once:
public int CarMakeID { get; set; }
private Make _carMake;
public Make CarMake
{
get
{
if (CarMakeID == default(int))
return null;
if (_carMake == null)
// fetch the Make from data and save it to _carMake
return _carMake;
}
}
David's solution is just fine but for some reason I find my own solution to better fit my needs and besides that I find it more elegant. So basically what I do is I create a class that holds the textual descriptions of all the properties that keep just ID. For example, I have the following model:
public class EmployeeModel{
public int EmployeeID {get;set;}
public string FullName {get;set}
*public int DepartmentID {get;set}
*public int SpecialityID {get;set;}
public int Age {get;set;}
}
The properties marked with asterisk are the properties that keep ids of possible many predefined options and when showing we're supposed to show the actual descriptions, not the number representations. So for this purpose, we create a separate class:
public class EmployeeTextValues{
public string DepartmentName {get;set;}
public string SpecialityName {get;set;}
}
And then I just add this class as a property to my model:
public EmployeeTextValues TextValues {get;set;}
After that, it's quite easy to access it from anywhere, including Razor.
P.S. I'm sure that a lot of people will tend to do the following before initializing this property:
Employee emp=new Employee;
emp.Age=25;
emp.TextValues.DepartmentName="Engineering";// Don't do this
If you try to access or set Textvalues.Someproperty you'll get Object reference not set to an instance of an object. So do not forget to set TextValues first to some initialized object. Just a kind reminder, that's all.
What is best way to map following classes?
I have classes where communication is "base" class as it contains shared data for either option. There can be only communication to ComSms or to ComEmail. The problem is i am unsure how to proceed with the mapping.
I would like if at all possible use one repository for accessing the Objects.
Class Set Up
public interface ICommunication
{
}
public Communication: ICommunication{
//PK and FK on this item
public virtual int CommunicationId{get;set;}
public virtual string Name {get;set;}
public virtual string Surname {get;set;}
public virtual DateTime Date{get;set;}
//I am expecting to switch on type between ComSms and ComEmail
public virtual Type {get;set;}
}
public ComSms : Communication{
public virtual string Number {get;set;}
public virtual string Text {get;set;}
}
public ComEmail : Communication{
public virtual string Subject{get;set;}
public virtual string Body {get;set;}
public virtual string Address {get;set;}
}
Database
Imagined usage
ICommunication smsToSave = new ComSms()
smsToSave.Name = "UserName";
smsToSave.Surname ="UserSurname";
smsToSave.Date = DateTime.Now;
smsToSave.Type = 1;
smsToSave.Number ="123456789";
smsToSave.Text = "Hello boys";
CommunicationRepository.Save(smsToSave)
I don't have time to write out any mappings but what you need is a discriminator. This would allow you to say have a CommunicationType foreign key in your table that could link to either the Sms or Email table. The nice thing about discriminators is that NHibernate takes care of everything for you.
And yes, seeing as your aggregate root is Communication then you could use one repository for accessing either of your communication types.
ok
i have resolved it by separated repositories that handles ever part of it instead
i could not bind it correctly, so chosen to go around the problem.
if you find any way of doing this please let me know
I have an object called "Comment" now a Comment can be associated with a "News" article OR a "Feature" article or a "Product". So will look something like:
public class Comment
{
[BelongsTo]
public Feature Feature
{get;set;}
[BelongsTo]
public News News
{get;set;}
[BelongsTo]
public Product Product
{get;set;}
}
Now obviously only 1 Feautre, Product, or News will be populated at a time, and all implement interface "IContent". So how do I get one property like:
[BelongsTo(Type = Change type at runtime!!)]
public IContent Content
{get;set;}
Any idea how to structure this?
Use [Any]. Docs about this here and here.
Can I have a data contract of this shape??
[DataContract]
public class YearlyStatistic{
[DataMember]
public string Year{get;set;}
[DataMember]
public string StatisticName {get;set;}
[DataMember]
public List<MonthlyStatistic> MonthlyStats {get;set}
};
I am assuming here that class MonthlyStatistic will also need to be a DataContract. Can you do this in a web service?
To use the same model for web services, mark your class as Serializable use the XmlRoot and XmlElement in the System.Xml.Serialization namespace. Here is a sample using your example:
[Serializable]
[XmlRoot("YearlyStatistic")]
public class YearlyStatistic
{
[XmlElement("Year")]
public string Year { get; set; }
[XmlElement("StatisticName")]
public string StatisticName { get; set; }
[XmlElement("MonthlyStats")]
public List<MonthlyStatistic> MonthlyStats { get; set; }
}
You will have to do the same thing for your complex object properties of the parent object.
Yep, thats standard WCF serialization right there. Are you trying to say the MonthlyStats collection has a property called WeeklyStats, or that each individual MonthlyStatistic has a WeeklyStat collection? If its the former, that doesnt work in WCF natively. You will have to do some fiddling in order to get it to work. If its the latter, its perfectly fine.
Yes, you can send the data contract you mentioned above back and forth from a WCF service. Like you said, MonthlyStatistic and all its members will have to be defined as data contracts themselves or be built in types (like strings).
You can even send and receive more complex types like when you have a base class but want to send or receive an object of a derived class (you would do that using the KnownType attribute). While receiving (de-serialization), from Javascript, there's a trick using which you have to specify the type for WCF. If you are interested, feel free to ask.