Попаднахме в много труден сценарий в един проект. Използвахме много размисли в нашия проект.
Ние имаме ..
- Рамка за валидиране, управлявана от атрибути и рефлексия
- Методи за разширение, които трансформират DataRow към обект на субект, използвайки атрибути и отражение и обратно. Същото нещо, което направихме за DataTable и EntityCollections.
- Интерфейс на IComparer, реализиран на общия клас EntityComparer, който използва отражение, за да сравни два обекта на Entity.
Подобно на горните сценарии, ние използвахме Reflections в много други части в нашето приложение. След използване на отражението забелязахме, че приложението предприема повече цикли на обработка с отражение.
До каква степен трябва да използваме Reflection в нашетопроект? Кои са областите на един проект, които са най-неблагоприятно засегнати от размисъл по отношение на обработката? Където отражението няма да окаже никакво въздействие? Има ли указания за използването на Reflection?
Отговори:
4 за отговор № 1Отражението е мощно, но има недостатъци. По принцип се опитайте да кодирате без него - но е изключително полезно за библиотеките с „рамка“, където имате малко / ограничени познания какви ще бъдат действителните обекти; например:
- ORM / DAL инструменти (зареждане / запазване на произволни данни)
- данни свързване
- сериализация
Има наказания за изпълнение с ad-hoc отражение, но ако ще го направите много (в рамките на вашата библиотека и в тесен цикъл) можете да я смекчите:
- като се използва
Delegate.CreateDelegate(като въведен делегира; не използвайтеDynamicInvoke) - чрез писане на динамичен IL
- като се използва
Expressionв .NET 3.5
И разбира се, всеки такъв код трябва да се кешира и да се използва повторно (не искате да компилирате + изпълнявате за всяко обаждане; само първото - останалото трябва просто да се изпълни).
Или има библиотеки, които абстрахират това; например, HyperPropertyDescriptor обвива потребителски IL (за членски достъп) в познатото PropertyDescriptor API - прави го много бърз, но безболезнен. Въпросът ви споменава таблици с данни и образувания; което звучи а много като този предишен въпрос, където направих някои показатели, използвайки HyperDescriptor, с обобщение (в милисекунди):
Vanilla 27179
Hyper 6997
Така че моето "вземане":
- в приложение; много малко - като краен случай, като цяло
- във вашия обща библиотека / библиотеки; където е подходящо (като се отбележи, че интерфейсите и др. са за предпочитане, когато е възможно)
1 за отговор № 2
Ако обувката пасва, тогава я носете ... Ако той реши проблема и не предизвика прекомерна обработка, измерена чрез някакъв вид тестване (за предпочитане профилер), тогава не се тревожете за това. Има много проблеми, които лесно се решават с размисъл.
Единствената насока, която имам по отношение на решаването да не използвам отражение, е да го използвам за влизане в свойства, до които обикновено нямаш достъп (т.е. частни имоти в нечий друг клас).
1 за отговор № 3
Вашето нефункционално изискване / QoS би трябвалодиктувайте дали е подходящо да използвате отражение или не, както при моя коментар, тест, тест, тест (единица, тест за ефективност и т.н.). Ако вашият клиент е доволен от производителността, бих казал, че отидете за това. Той може и наистина дава известна печалба от производителността, когато се използва правилно.
Лично аз ще избера да не използвам размисъл, когато мога.
1 за отговор № 4
Отражението може да осигури реални ползи заразширяемост и гъвкавост. При използване на размисъл има хит на производителността, но това не бива да ви отлага незабавно, особено ако това ви носи повече ползи. Опитайте се да използвате отражението умерено, но не предполагайте, че ще навреди много, за да използвате, когато трябва. Тази статия е добра по тази тема: http://www.west-wind.com/weblog/posts/351.aspx
1 за отговор № 5
Моят съвет е винаги да се опитвате да намерите обектпърво ориентирано решение, а не прибягване до размисъл при първата възможност. Може да е по-лесно да постигнете нещо с размисъл, но като цяло кодът става по-организиран с OO решение и вие се освобождавате от режима на размисъл.
През годините си като разработчик съм използвал саморазмисъл два пъти ... Първият беше да получите достъп до някаква частна променлива, за да постигнете напредък в качването на уеб заявка. Второто беше динамично създаване на обекти на обекти при четене от четец на данни, което по-късно с радост замених с общо решение.