НахлобучА ведь стоило всего-то немного
подумать :
1.
2.
3.
4.
5.
6.
7.
public abstract class PersonAccessor : DataAccessor
{
[SqlText(@"SELECT * FROM Person WHERE FirstName = @firstName")]
public abstract List<Person> GetPersonListByFirstName(string @firstName);
[SprocName("sp_GetPersonListByLastName")]
public abstract List<Person> GetPersonListByLastName(string @lastName);
}
И что этот пример доказывает?
Комменты в студию
Нахлобуч"Неудобно" -- это детский сад. Что конкретно не устраивает?
Не устраивает объем кода, необходимый для начала работы, например, со списком (неважно, каким, просто селект из таблицы)
Причем не только загрузить и показать, но и при изменении значения, скажем, в гриде сразу автоматически отражать его в таблице на сервере
Неудобно тянуть все на клиента, если например большая номенклатура.
Неудобно делать фильтры на обновляемых списках.
Ссылка - незачет. Три года назад они только начали
Вообще, технология ОРМ пока слишком сырая. Подожду, пока микрософт включит что-нибудь такое в состав SQL Server. Пока все это крутится на клиентской машине, о нормальной скорости говорить нельзя.
Нахлобуч Более чем уверен, что это все от незнания ADO.NET и прочего.
Интерестная точка зрения. Ну-ка раскажи, что я должен знать об ADO.NET 8)
Нахлобуч А ты не пиши код, который не имеет смысла -- только и всего.
Хорошее пожелание.
Мусорный код (не имеющий смысла для _для пользователя_) - это код, не работающий для пользователя.
Расчет себестоимости при отгрузке накладной - это код имеющий смысл.
А вот классы, которые занимаются приемом\передачей данных в SQL (ADO.NET) - это мусор, так как пользователю пофиг, как его данные попадают на сервер.
Классы бизнес-обьектов - мусор, т.к. опять же пользователю все равно, как программист хранит данные внутри программы.
И даже всеми горячо любимая религия юнит-тестов - опять же мусорный код, т.к. до пользователя он вообще не дойдет.
Этот код все же нужен, но далеко не в тех объемах, в каких его применяют.
