Отлично, допустим, я проектировщик интерфейсов, по моему проекту на форме ввода есть 3 поля для ввода даты рождения и я хочу, что бы подсвечивались только не правильные поля.
Возможно придется отдельное место прописывать для ошибки. Или для каждого отдельного поля продублировать сообщение (не знаю как лучше)
Попытка адаптации интерфейса под внутреннее устройство, это плохо, изменения в одном не должны особо влиять на другое.
Проверку ограничений лучше не включать в саму сущность, проверка может зависеть от окружения, например для разных пользователей могут быть разные ограничения. По этим причинам кастомный экспшн лишний. Хотя совершенно не ясно, как проверка команд решает проблему определения
class Program
{
[STAThread]
static void Main( string[] args )
{
IUnityContainer container = new UnityContainer();
container.RegisterViewModel<DataAop>();
var dataAop = container.Resolve<DataAop>();
List<IData> listOfData = new List<IData>();
listOfData.Add( dataAop );
var asm = System.Reflection.Assembly.GetExecutingAssembly();
var excludes = new HashSet<Type> { typeof( IData ), typeof( DataAop ), typeof( ProxyData ), typeof( DataObservableObject ) };
listOfData.AddRange( asm.GetTypes()
.Where( t => typeof( IData ).IsAssignableFrom( t ) && !excludes.Contains( t ) ).Select( t => Activator.CreateInstance( t ) as IData ) );
foreach (var notify in listOfData.Cast<INotifyPropertyChanged>())
notify.PropertyChanged += OnPropertyChanged;
DataObservableObject observableData = new DataObservableObject();
var propDesp = DependencyPropertyDescriptor.FromProperty( ObservableObject<int>.ValueProperty, typeof( ObservableObject<int> ) );
propDesp.AddValueChanged( observableData.RealValue, OnPropertyChanged );
listOfData.Add( observableData );
Console.WriteLine( string.Format( "Start ---> {0}", DateTime.Now ) );
Stopwatch sw = new Stopwatch();
foreach (var data in listOfData)
{
sw.Restart();
for (int i = 0; i < 10000000; i++)
data.Value = i;
sw.Stop();
Console.WriteLine();
Console.WriteLine( string.Format( "Iteration date {0}, data name {1}, elapsed {2}",
DateTime.Now, data.GetType().Name, sw.ElapsedMilliseconds ) );
}
Console.WriteLine( string.Format( "Stop ---> {0}", DateTime.Now ) );
Console.ReadKey();
}
static void OnPropertyChanged( object sender, EventArgs e ) { }
static void OnPropertyChanged( object sender, PropertyChangedEventArgs e ) { }
}
интерфейс улиток (эх название у интерфейса подкачало)
public interface IData
{
int Value { get; set; }
}
пример реализации
class DataString : BindableBase, IData
{
int _value;
public int Value
{
get
{
return _value;
}
set
{
if (_value != value)
{
_value = value;
OnPropertyChanged("Value");
}
}
}
}
особо опасная реализация
class DataObservableObject : IData
{
public DataObservableObject()
{
RealValue = new ObservableObject<int>();
}
public ObservableObject<int> RealValue { get; private set; }
public int Value
{
get
{
return RealValue.Value;
}
set
{
RealValue.Value = value;
}
}
}
запустил тест на другом компьютере, и вот результат
Ну знаю я далеко не все
Стандартный путь дзена — быдлокодинг -> шаблоны -> solid -> быдлокодинг -> просветление
на самом деле очень важно работать в команде и обмениваться знаниями, а так же критика
И какие интерфейсы стоит изучать в первую очередь(.NET)?
Атрибут, появился в с#5 https://msdn.microsoft.com/ru-ru/library/system.runtime.compilerservices.callermembernameattribute(v=vs.110).aspx
имя подставляется во время выполнения
можно посмотреть https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices(v=vs.110).aspx
В целом поддерживаю, за исключением четвертой улитки, хорошая альтернатива nameof в условиях отсутствия c# 6 версии. Ну и про тормознутый список говорил не юниор, а разработчик которому было искрнни лень исправлять проблемный код
Истерики нет, меня вполне устраивает класические OnPropertyChanged через expression,
например, не поставить брэкпоинт
при написании IInterceptionBehavior это не проблема.
У ObservableObject интересная наследственность System.Windows.FrameworkElement<-Microsoft.Practices.Prism.ObservableObject + странный биндинг, не уверен что это чистый код. Автоген это конечно круто, а чем вынос дыма в partial лучше наследования или композиции?
Это никак не уменьшает объем писанины по сравнению с IQueryable. В совокупности с билдерами даже увеличивает.
я не разу ни где не писал, что объем уменьшиться
Во-первых можно передать пустой запрос и в этом случае ни один из билдеров не сработает и будет втянута вся таблица.
пустые запросы можно отслеживать
Во-вторых почти всегда есть кейс — показать все записи в UI в виде таблицы или четь в этом роде
если записей не много то да. Вы реально хотите увидеть таблицу в UI из 999999 ( да же не миллион ) записей?
Во-третьих, даже если вы требуете передавать параметры пейджинга, то никто не помешает передать размер страницы равный int.MaxValue.
вы вообще читаете то что я вам пишу?
ну наверное пропустить 0 взять 1000000 ( за такой запрос медаль только за храбрость и дадут ),
Сколько я не видел репозиториев — почти все позволяли втянуть всю таблицу, а разработчики этим активно пользовались.
а вот это вообще шикарно, в итоге мы получаем неизвестность в плене выполнения запросов, и как результат дубляж запросов по коду, при частых изменениях в бизнесе, модификации объектов — смерть.
Попытка адаптации интерфейса под внутреннее устройство, это плохо, изменения в одном не должны особо влиять на другое.
но мы ж не улитки
вот код программы
интерфейс улиток (эх название у интерфейса подкачало)
пример реализации
особо опасная реализация
запустил тест на другом компьютере, и вот результат
разница не велика
KindOfMagic например, это статическое АОП
Стандартный путь дзена — быдлокодинг -> шаблоны -> solid -> быдлокодинг -> просветление
на самом деле очень важно работать в команде и обмениваться знаниями, а так же критика
что есть интерфейс?
имя подставляется во время выполнения
можно посмотреть https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices(v=vs.110).aspx
1) KindOfMagic build task runs just after compilation.
не использовал, но наслышан, а на сколько замедляет сборку приложения?
У ObservableObject интересная наследственность System.Windows.FrameworkElement<-Microsoft.Practices.Prism.ObservableObject + странный биндинг, не уверен что это чистый код. Автоген это конечно круто, а чем вынос дыма в partial лучше наследования или композиции?
пустые запросы можно отслеживать
если записей не много то да. Вы реально хотите увидеть таблицу в UI из 999999 ( да же не миллион ) записей?
вы вообще читаете то что я вам пишу?
а вот это вообще шикарно, в итоге мы получаем неизвестность в плене выполнения запросов, и как результат дубляж запросов по коду, при частых изменениях в бизнесе, модификации объектов — смерть.
1. Создание объекта
2. Сохранение
3. Объекты бизнеса могут отличаться от хранимых — это маппинг
Где все это делать?