Доброго всем времени суток. Впервые пишу трёхслойное приложение, и хотелось бы посоветоваться с более опытными разработчиками. Для доступа к бд использую linq to sql, с помощью которого генерирую классы по таблицам в sql. Раньше когда всё приложение располагалось в одном проекте я использовал ключевое слово partial когда хотел добавить какую то логику или вспомогательные методы в эти классы. Сейчас когда весь слой бизнес логики вынесен в отдельный проект такой подход не работает. Поэтому для описания логики и валидации приходиться оборачивать эти классы и добавлять нужные мне методы и в слой представления передавать коллекции уже этих классов обёрток. А так как в слое представления использую wpf и шаблон  mvvm приходиться эти бизнес классы оборачивать ещё раз. Смотрю я вот на всю эту махину и нифига мне не нравиться что получилось в итоге. Подскажите плиз на сколько это правильный подход. И по возможности поделитесь ссылками на похожие опенсоурс проекты,а то я ничего вразумительного найти не смог. заранее благодарю за помощь.. 

Тут многое зависит от размера и сложности проекта.

А почему нельзя сделать shared сборку где будут все linq to sql классы вместе с бизнес логикой и все слои приложения будут их видеть?
Думаю можно так же в классы linq to sql запихнуть и механизмы для WPF(INotifyPropertyChanged и тп).

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

В более продвинутом проекте может потребоваться более жестко отделить все слои друг от друга и тогда действительно надо будет создавать обертки. Сервис работает с linq to sql, передает данные в виде xml клиенту, а клиент оборачивает их в свои классы, работает с ними и отсылает обратно.

Посмотрите на Entity Framework и Self Tracking Entities. В EF есть механизмы для построения многоуровневых приложений. Объекты можно выгрузить из контекста, передать клиенту, далее получить их измененными от клиента и просто положить обратно в контекст и сохранить.

http://msdn.microsoft.com/en-us/library/bb896304.aspx

Я лично на практике не использовал EF в многоуровневом приложении, у нас используется свой ORM, но подходы одинаковы.
Есть низкий уровень представления данных, с простым классом представления данных который удобно передавать на клиент.
И более высокий уровень - контекст и обертки этих данных, с lazy loading и другими вещами для WFP.

спасибо за ответ и за ссылку, действительно узнал кое что новое. К сожалению EF применить не могу так как по условию задания ограничен именно Linq to Sql, и в один проект всё запихать нельзя так как проект учебный и требует именно чёткой организации архитектурных слоёв.Я вот делаю так, допустим у нас есть таблица в бд Person с полями Name CountMoney. Использую визуальный редактор Linq to sql создаю dataContext, заодно и генерируется класс

Этот класс я использую в слое доступа к данным например с шаблоном repository
Дальше в слое бизнес логики мне нужно сделать какие вычисления с полем CountMoney для этого я делаю класс обёртку и добавляю в него нужные методы

в таком виде обьекты и передаю в слой представления там создаю ещё обёртку над этим классом куда добавляю свойства для Wpf
 
В принципе такой подход вполне работает, но мне очень не нравиться что каждый слой плодит свои сущности и если количество классов велико то это сильно усложнит приложение. Вот и хотелось бы услышать мнение людей имеющих практический опыт с приложениями корпоративного уровня,правильный ли это подход и если можно поделиться ссылками на исходники реальных проектов с такой архитектурой.
P.S  не очень понимаю почему модераторы перекинули в WPF и Silverlight, так как вопрос больше о архитектуре чем  конкретно об этих техноглогиях

В общем все так, уровень данных(linq to sql), потом уровень бизнес логики. А вот PersonViewModel чем собственно занимается?

На практике мы создаём контроллеры для отдельных сущностей или же чаще для отдельных бизнес процессов(можно читать контролов), которые и реализуют бизнес логику и все что надо для WPF.

Далее уже идет смешанный режим работы в зависимости от ситуации. Либо работаем через наш ORM, загружая, изменяя и сохраняя данные. Либо же вызываем сервисные методы которые реализуют бизнес логику.

Слой доступа к данным генерируется сам.
Если на стороне сервисов нужен класс реализующий бизнес логику - то его надо сделать.
Если на стороне клиента нужен класс реализующий бизнес логику - то его тоже надо сделать.

Если есть требования по четкому разделению слоёв или это что-то дает, то вполне можно это все реализовать.

ViewModel   хранит логику для представления например какой элемент в данный момент выделен ну и реализует интерфейс INotifyPropertyChanged, это по шаблону mvvm, ну в общем спасибо за то что разрешили мои сомнения по поводу моего подхода. Ещё бы кто помог ссылками на реальные проекты..