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

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

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

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

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

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

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

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

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

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

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

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

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

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