SPMETAL/LINQ to SharePoint Десятичные типы

Question

Я ударил довольно крупную ошибку с объектами, созданными spmetal/linq для sharepoint. Я надеюсь, что кто-то справился с этим раньше .. или, может быть, я упустил что-то очевидное.

Предположим, у нас есть список с полем цифр. Ожидается, что поле будет содержать достаточно точные значения. Например, 0.0000451. После того, как значение находится в списке, SharePoint отлично справляется с этим. Он отображает в списке и отображает/редактирует представления правильно.

Теперь, если мы создаем объекты на основе этого списка с SPMetal, мы получим ..

//... 
private System.Nullable<double> _number; 
//.. 
[Microsoft.SharePoint.Linq.ColumnAttribute(Name="Number", Storage="_number", Required=true, FieldType="Number")] 
public System.Nullable<double> Number { 
    get { 
     return this._number; 
    } 
    set { 
     if ((value != this._number)) 
     { 
      this.OnPropertyChanging("Number", this._number); 
      this._number= value; 
      this.OnPropertyChanged("Number"); 
     } 
    } 
} 
//... 

Поскольку тип определяется SPMetal является double мы получаем обозначение при попытке извлечь его .. например:

var number = (from x in myDc.MyList select x.Number).First(); 

номер фактически приведет к двойному номеру 4.51E-05, а не 0.0000451.

Я предполагаю, что это можно исправить с помощью десятичной дроби. Если я изменю типы по всем сгенерированным объектам на System.Nullable<decimal>, я получаю ошибки преобразования типов.

Как это исправить?

EDIT Я думаю, может быть, лучше спросить «как мне с этим справиться»? например, я могу просто преобразовать мои двойные значения в десятичные числа позже в строке. Например, мой запрос linq. Если я это сделаю, примерный пример вернет ожидаемый результат. Однако это кажется неуклюжим, и я хотел бы исправить это у источника.

Answer 1

4.51E-05 фактически равно 0.0000451, так что с вашим кодом нет ничего плохого.

Другими словами 4.51E-05 означает 4,51 раз десять в минус пять мощности или 0.0000451

Answer 2

Есть несколько подобных случаев, когда SPMetal даст вам неуклюжим код. Вы можете и иногда должны это исправить. И я признаю, что определенно лучше сделать это у источника. Но есть недостаток.

При изменении модели данных вам придется повторно запустить SPMetal, чтобы включить новые объекты. Любые изменения, внесенные в сгенерированный файл, должны быть тщательно задокументированы и переделаны, или ваш код будет нарушен. Поэтому я бы посоветовал оставить только сгенерированный код, если вы можете с ним работать.

Если вы можете написать обертку вокруг объектов/методов, было бы, конечно, предпочтительнее просто преобразовывать типы в конечной точке, но это общая хорошая практика программирования.