Рубрика «generic object»

в 12:46, , рубрики: .net, activator, C#, expression, generic object, высокая производительность, ооп

0. Лирика

Поговорим про unit тестирование. Для больших и возрастных проектов весьма актуальна проблема «толстых» сервисов. Я сейчас говорю про большое количество зависимостей передаваемых в конструктор. Если к этому добавить несколько десятков методов, которые необходимо тестировать, становится очевидно, что тратится много времени на мокирования ненужных частей. Решить проблему поможет автоматизация,. т.е. создание экземпляра необходимого типа и мокирование неиспользованных зависимостей в процессе выполнения.

Получается нам нужно

var myService = new MyService(A.Fake<ISevice1>(), new Sevice2(), 
               A.Fake<ISevice3>(), A.Fake<ISevice4>(), 
               A.Fake<ISevice5>(), A.Fake<ISevice6>())

заменить на нечто похожее. Напоминает паттерн builde, не так ли?

 var myService = GetInstance<MyService>().With(new Sevice2()).Subject;

Главное не переборщить с автоматизацией. Производительность тоже важна, особенно если в проекте несколько десятков тысяч тестов, которые будут запускаться как локально, так и в настроенном CI.

Разумеется нам не обойтись без рефлексии.
Читать полностью »

в 14:25, , рубрики: generic object, mongodb, reflection, Программирование, Совершенный код, метки: , , ,

Первая попытка получилась немного сумбурна, поэтому я решил написать более последовательно.

Повторим основную идею: работу с базой нужно организовать через специально заточенный класс, а не разбрасывать код вызовов по всему проекту.

Но этому может препятствовать то, какой интерфейс предлагают производители баз данных. Мы потренируемся на базе MongoDB.

Здесь я предложу реализацию следующей логики работы:

Должен быть базовый класс, от которого наследуются все классы, которые будем сохранять в базе, пусть это будет DBData. Тогда у него будут просто 3 метода: Load, Save, Delete. А обращение к базе уже будет делом DBData.

Польза от такой концепции должна быть очевидна — пользователь объектов может не думая о реализации и нюансах баз данных просто сохранять и восстанавливать свои объекты. Но на этом пути есть ряд сложностей. Рассмотрим их.

Читать полностью »

в 18:30, , рубрики: generic object, mongodb, reflection, Программирование, Совершенный код, метки: , , ,

Предисловие

В моем первом посте на Хабре завязался такой диалог:

A. важно, что к базе нельзя обращаться прямо, только через хранимые-процедуры, а за вызов хранимой процедуры ответственен определенный класс

B. «только через хранимые-процедуры» — что же вы NoSQL-продуктам скажете?

Дальше акцент сместился SQL vs. NoSQL. Но были потеряны основы: работу с базой нужно организовать через специально заточенный класс, а не разбрасывать код вызовов по всему проекту.

Я по прежнему считаю, что NoSQL — это слишком молодые продукты, чтобы они могли конкурировать с реляционными базами на полном серьезе. Но у NoSQL и несколько другая ниша. Мне понадобилось некоторое сохранение данных в проекте, где нет больших объемов. И поэтому я решил попробовать MongoDB. (я бы лучше поработал бы с Oracle NoSQL Database, но не нашел как с этим работать на C#).

Ну в общем все достаточно хорошо, чтобы сохранить объект в базе, оказалось надо сделать совсем мало:

var collection = db.GetCollection();
collection.Save(argObject);

где StrategiesData — тип моего объекта, argObject — собственно мой объект. Но такой стиль поощряет раскидывать как раз обращение к базе по всему проекту. Мешает явное указание типа вида . Ну, что остается отображение. Об этом и поговорим.

Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js