самое грамотное решение - это, безуловно, отделение логики от представления. Имхо не важно будет ли эта логика разделена отдельными проэктами (что по-сути более удобно) или в одном проэкте на уровне, например, пространств имен (что менее удобно из-за излишнего загромождения классами, но для небольших проэктов вполне приемлемо).
Насчет тупых internal static classes немного не согласен (хотя это может быть делом вкуса). Предпочитаю не модульные классы (так называемые Table Modules) а бизнес объекты, которые на базовом уровне умеют работать с абстрактным источником данных (не зависимым от провайдера). А на верхнем уровне (конкретные реализации для доступа к отдельной ,например, табличке) содержат всю бизнес-логику/правила. Есть кстати хорошая книга по написанию н-уровневых приложений с использованием бызнес-объектов, правда примеры на vb:
Expert One-on-One Visual Basic .NET Business Objects
by Rockford Lhotka ISBN:1590591453


_______________________________________________________
Never ask users what they want, or they'll tell you.