Въпроси по проект

1. Знам, че принципно казахте напишете mail, но ми изглежда по правилно да попитам публично (в случай, че и на някой друг му е полезен отговора).

   В крайна сметка имам желанието да напиша (сравнително) прост restful web service, който :

   • да работи с FirebirdSQL (дълга история, но такова нещо ми трябва и съм си харесал с кой gem да стане)
   • да може да извлича данни в json (и може би xml)
   • да може да извлича данни в прост html - за проверка от двукрак софтуер
   • да може да налива известен набор неща към базата

   Имам няколко въпроса по идеята :

   1. Подходящо ли е?

   2. Въпреки че 50 реда проект на Sinatra е много, мога ли това да ползвам, ако си надробя нещата културно по файлове? Реално Rails ми идва като да стрелям по врабче с топ, а ще ползвам чужда база и няма да имам полза от ORM.

   3. В каква насока би следвало да са ми тестовете? Изобщо, когато се тества приложение с база данни, има ли по-културен начин да се провери от cp clean-database currentdatabase преди всеки тест?

   4. Какви са ми ограниченията?

   Публикувано преди почти 13 години
2. 1. Щом си се надъхал, действай :)
   2. Sinatra е окей, стига да не ти е overly complicated дизайна. Но внимавай много с това, което Стефан обясни за bottom-up дизайн. По-трудно е и е по-вероятно да омажеш нещата. Ти си преценяваш :)
   3. Има — mocking, stubbing и евентуално feed-ване с няколко реда тестови данни преди всеки тест. Виж кода на Evans и разгледай spec/-овете.
   4. Ако имаш предвид Skeptic-ограниченията, ще ги определяме на малко по-следващ етап. Не прекалявай с дължината на редовете, с броя редове в метод, с броя методи в клас... :)

   Публикувано преди почти 13 години

3. Всичко прекрасно, полага ли ми се 1 файл амнистия, в който да си опиша SQL-ите, понеже съм писал заявки по над килобайт?

   Публикувано преди почти 13 години

4. Bottom-up — ако няма миграции в Синатра, ти трябва да прецениш какво да направиш по въпроса. Ако няма да ползваш ORM, но имаш супер сложни заявки, ти трябва да прецениш какво е най-добре да се направи по въпроса :)

   Аз при всяко положение не бих оставил SQL да се мотае из кода. Бих те посъветвал все пак да пишеш класове, които да ти енкапсулират SQL-а и ти да викаш техни методи, за да постигаш желаните си цели. (Това малко наподобява на ORM, който ти си пишеш.) И все пак си мисля, че би имал нужда от някакъв базов клас за въпросните класове и в крайна сметка нещата отиват към твой собствен ORM :) Ако държиш SQL-ът да не ти е в самите класове-модели, а в някакъв конфигурационен файл, бих ти казал следното — решението си е твое, но аз не бих го направил така. Аз бих си вкарал SQL-а в класовете, както ти казах. И бих имал някакъв базов клас, който ми дефинира някакви generic CRUD-методи, за да направя кода си по- DRY.

   Много внимавай с тоя bottom-up :) Сложен е и ако излезе боза, която не ни хареса, ще ти дърпаме ушите :))

   Публикувано преди почти 13 години

5. Към момента идеята ми е в класовете да няма почти нищо, но чисто и просто някои неща ми се извличат с болезнено дълги заявки (по смъртно не мога да вместя някои от тях в 100 знака), а ми се ще да не правя добавки в чуждата база.

   Публикувано преди почти 13 години

Трябва да сте влезли в системата, за да може да отговаряте на теми.