can i set value for a property like this
public string MyProperty { get { return _GetValue(); } set { _GetValue(); } }
public static string _GetValue()
{
string name = null;
using (HROEF.Entities context = new HROEF.Entities())
{
var result = (from my linq Statement).First().ToString();
name = result;
}
return name;
}
In my View
#Html.DisplayFor(model=>Model.MyProperty)
is there any thing wrong in this?
It is not displaying the value in my view
any help?
In general, you shouldn't be doing database accessin properties. It's just bad practice. Properties should not perform lengthy operations that can time out, or have other issues.
As for why it's not showing your value, that's hard to say. Most likely, your linq query simply isn't returning any results.
Related
I'm only at chapter 5 in "Essential C#" and not sure if i understand the difference correctly. I tried to make the model below to test one instance of everything in the properties chapter - and it works - but is the example acceptable use of the two ways one can implement properties or are there better ways?
using MarkdownSharp; // StackOverflow's md processor
public class Article
{
public string Headline { get; set; }
public string Content
{
get
{
return _content;
}
set
{
var md = new Markdown();
var html = md.Transform(value);
_content = html;
}
}
private string _content;
public DateTime Published { get; set; } = DateTime.Now;
}
This question may be better suited for codereview.stackexchange, although it's perhaps too tiny a snippet and to vague a question for that.
Personally, I shy away from magic properties that act in surprising ways. It tends to make for APIs that can be hard to use because they are surprising, even if they are somehow “clever” under the hood. You have a property where you set a different value than the one you get out. One thing where this can break would be the += operator, which suddenly would work in very weird ways with your Content property.
I'd probably go with something like
public class Article
{
private string content;
private string renderedContent;
public string Headline { get; set; }
public string Content
{
get { return content; }
set
{
content = value;
renderedContent = null; // reset cached rendered content
}
}
public string RenderedContent
{
get
{
if (renderedContent == null)
{
renderedContent = new Markdown().Transform(content);
}
return renderedContent;
}
}
public DateTime Published { get; set; } = DateTime.Now;
}
As for whether to use field-backed properties, or auto-properties, or computed properties ... that's up to you to decide based on what the property is supposed to do. Auto-properties are fine for simply storing and retrieving a value, e.g. Published or Headline here. You need the explicit backing field as soon as you do something more than just reading or writing it in the getter and setter, as shown here in Content. RenderedContent could be just a computed property, but I chose to cache the value after initial conversion because you kinda do the same. This pattern here doesn't convert the Markdown until it's actually needed, though.
I've got an issue with a list property that holds bookmarks. Before I started fiddling around it worked just fine.
I want the list to always be sorted from a-z when fetched and I want the list to be able to set to the value put in.
I am not sure why it won't work. Any suggestions on getting the latter to work, or any suggestions to sort the list in any other manner is greatly appreciated and welcome!
Here the bookmark list is being set from a database query:
model.Bookmarks = GetBookmarks().Select(b => new UIBookmark(b, DbHelper)).ToList();
This worked:
public List<UIBookmark> Bookmarks { get; set; }
This doesn't:
public List<UIBookmark> Bookmarks { get { return Bookmarks.OrderBy(b => b.Name).ToList(); } set { Bookmarks = value; } }
If you are not using auto-properties, you HAVE TO use a field to store your data.
private List<UIBookmark> _bookmarks;
public List<UIBookmark> Bookmarks { get { return _bookmarks.OrderBy(b => b.Name).ToList(); } set { _bookmarks = value; } }
Basicly, auto-properties do the same thing, you just don't have to write anything.
You will want to use a backing field instead of referencing the property itself in the getter and setter, like so:
private List<UIBookmark> _bookmarks;
public List<UIBookmark> Bookmarks { get { return _bookmarks.OrderBy(b => b.Name).ToList(); } set { _bookmarks = value; } }
MSDN has some good articles introducing the concepts of Properties and Auto-Properties that I would suggest reading up on too.
I have the following property in my model:
//PRODUCTS
private ICollection<int> _productIds;
[NotMapped]
public ICollection<int> ProductIds
{
get { return Products.Select(s => s.Id).ToList(); }
set { _productIds = value; }
}
When my code returns a new instance of this model, the set accessor doesn't seem to take. In other words, I can see that the get accessor is appropriately returning a collection of product ids, but when I attempt to assign using the set, the value is an empty List<int>. For example:
var result = new Application
{
Id = application.Id,
. . .
ProductIds = application.ProductIds //<--this is a list of integers,
// but the new "result" object shows an empty list.
};
It is very unusual to have get and set for one property to work of different sources. You may want to remove set altogether if you always read the value from somewhere else.
Maybe you are looking to override value of the property (i.e. for unit testing) like this:
[NotMapped]
public ICollection<int> ProductIds
{
get { return _productIds != null ?
_productIds // return one that was "set"
: Products.Select(s => s.Id).ToList(); // read from DB
}
set { _productIds = value; }
}
Lets imaging the we have model:
public class InheritModel
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public string OtherData { get; set; }
}
We have a controller with View, that represents this model:
private InheritModel GetAll()
{
return new InheritModel
{
Name = "name1",
Description = "decs 1",
OtherData = "other"
};
}
public ActionResult Index()
{
return View(GetAll());
}
Now we can edit this in View, change some data and post in back to server:
[HttpPost]
public ActionResult Index(InheritModel model)
{
var merged = new MergeModel();
return View(merged.Merge(model, GetAll()));
}
What i need to do:
In view we have a reproduction of model
User change something and post
Merge method need to compare field-by-field posted model and previous model
Merge method create a new InheritModel with data that was changed in posted model, all other data should be null
Can somebody help me to make this Merge method?
UPDATE(!)
It's not a trivial task. Approaching like:
public InheritModel Merge(InheritModel current, InheritModel orig)
{
var result = new InheritModel();
if (current.Id != orig.Id)
{
result.Id = current.Id;
}
}
Not applicable. It's should be Generic solution. We have more than 200 properties in the model. And the first model is built from severeal tables from DB.
public InheritModel Merge(InheritModel current, InheritModel orig)
{
var result = new InheritModel();
if (current.Id != orig.Id)
{
result.Id = current.Id;
}
if (current.Name != orig.Name)
{
result.Name = current.Name;
}
... for the other properties
return result;
}
Another possibility is to use reflection and loop through all properties and set their values:
public InheritModel Merge(InheritModel current, InheritModel orig)
{
var result = new InheritModel();
var properties = TypeDescriptor.GetProperties(typeof(InheritModel));
foreach (PropertyDescriptor property in properties)
{
var currentValue = property.GetValue(current);
if (currentValue != property.GetValue(orig))
{
property.SetValue(result, currentValue);
}
}
return result;
}
Obviously this works only for 1 level nesting of properties.
Per topic, it seems that what you want is a sort of "change tracking" mechanism which is definitely not trivial or simple by any means. Probably, it makes sense to use any modern ORM solution to do that for you, does it?
Because otherwise you need to develop something that maintains the "context" (the 1st level object cache) like EF's ObjectContext or NH's Session that would be generic solution.
Also, there is no information on what happens at the lower level - how do you actualy save the data. Do you already have some mechanism that saves the object by traversing it's "non-null" properties?
I have a similar project experience, which made me thought a lot about the original design. Think the following question:
You have a view that representing a model, then users modified
something of the model in the view, all the CHANGES are posted to
server and the model is modified, and then it's saved to database
probably. What's posted to the server on earth?
An instance of InheritModel? No. You want the changes only. It's actually part of InheritModel, it's a InheritModel Updater, it's an instance of Updater<InheritModel>. And in your question you need to merge two models, because your Update method looks like:
public InheritModel Update(InheritedModel newModel)
{
//assign the properties of the newModel to the old, and save it to db
//return the latest version of the InheritedModel
}
Now ask yourself: why do I need a whole instance of InheritedModel when I just want to update one property only?
So my final solution is: posting the changes to the controller, the argument is something like a Updater<TModel>, not TModel itself. And the Updater<TModel> can be applied to a TModel, the properties metioned in the updater is assigned and saved. There shouldn't a MERGE operation.
How to avoid redundant second query to database with using MVVM pattern on view model:
public class DataFormViewModel : INotifyPropertyChanged
{
private int companyId
public int CompanyId
{
get { return companyId; }
set
{
companyId = value;
RaisePropentyChanged("FindingStatuses");
RaisePropentyChanged("StatusCount");
}
}
public List<FindingStatus> FindingStatuses
{
get
{
return FindingStatusService.GetAvalableStatuses(CompanyId);
}
}
public int StatusCount
{
get { return FindingStatuses.Count; }
}
}
i.e. when CompanyId was changed by DataBinder FindingStatuses will be executed and then StatusCount will be executed, that will execute FindingStatuses again.
I'm not sure I'd bind the property directly to a database operation in the first place. Why not have a local List<FindingStatus> representing the "last fetched" statuses, and then explicitly refresh it?
Apart from anything else, property access is usually expected to be reasonably cheap - making a database call every time you access either of those properties sounds like a bad idea to me.
Like Jon already mentioned, accessing properties are expected to be cheap, something you can do a thousand times without any sideeffect.
I would cache the result of your database access and return the cached object on any following request. Ie
private IList<FindingStatus> _findingStatuses;
public IList<FindingStatus> FindingStatuses
{
get
{
if (_findingStatuses == null)
{
_findingStatuses = FindingStatusService.GetAvalableStatuses(CompanyId);
}
return _findingStatuses;
}
}
And then you would of course have to clear your cache before raising the notification
public int CompanyId
{
get { return companyId; }
set
{
companyId = value;
_findingStatuses = null;
RaisePropentyChanged("FindingStatuses");
RaisePropentyChanged("StatusCount");
}
}
The best way to avoid multiple (and useless) queries to the database, is implement a simple cache layer in the Data Access Layer.
1- Ask the cache if he already has an updated result
2- Else query the database
Here is a cache class you can try: http://www.codeproject.com/KB/recipes/andregenericcache.aspx