| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > WPF и Silverlight > о трёхуровневой архитектуре |
| Автор: GRemlin87 18.12.2011, 17:41 |
| Доброго всем времени суток. Впервые пишу трёхслойное приложение, и хотелось бы посоветоваться с более опытными разработчиками. Для доступа к бд использую linq to sql, с помощью которого генерирую классы по таблицам в sql. Раньше когда всё приложение располагалось в одном проекте я использовал ключевое слово partial когда хотел добавить какую то логику или вспомогательные методы в эти классы. Сейчас когда весь слой бизнес логики вынесен в отдельный проект такой подход не работает. Поэтому для описания логики и валидации приходиться оборачивать эти классы и добавлять нужные мне методы и в слой представления передавать коллекции уже этих классов обёрток. А так как в слое представления использую wpf и шаблон mvvm приходиться эти бизнес классы оборачивать ещё раз. Смотрю я вот на всю эту махину и нифига мне не нравиться что получилось в итоге. Подскажите плиз на сколько это правильный подход. И по возможности поделитесь ссылками на похожие опенсоурс проекты,а то я ничего вразумительного найти не смог. заранее благодарю за помощь.. |
| Автор: Gvozdin 18.12.2011, 20:39 |
| Тут многое зависит от размера и сложности проекта. А почему нельзя сделать 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. |
| Автор: GRemlin87 21.12.2011, 07:00 | ||||||
спасибо за ответ и за ссылку, действительно узнал кое что новое. К сожалению EF применить не могу так как по условию задания ограничен именно Linq to Sql, и в один проект всё запихать нельзя так как проект учебный и требует именно чёткой организации архитектурных слоёв.Я вот делаю так, допустим у нас есть таблица в бд Person с полями Name CountMoney. Использую визуальный редактор Linq to sql создаю dataContext, заодно и генерируется класс
Этот класс я использую в слое доступа к данным например с шаблоном repository Дальше в слое бизнес логики мне нужно сделать какие вычисления с полем CountMoney для этого я делаю класс обёртку и добавляю в него нужные методы
в таком виде обьекты и передаю в слой представления там создаю ещё обёртку над этим классом куда добавляю свойства для Wpf
В принципе такой подход вполне работает, но мне очень не нравиться что каждый слой плодит свои сущности и если количество классов велико то это сильно усложнит приложение. Вот и хотелось бы услышать мнение людей имеющих практический опыт с приложениями корпоративного уровня,правильный ли это подход и если можно поделиться ссылками на исходники реальных проектов с такой архитектурой. P.S не очень понимаю почему модераторы перекинули в WPF и Silverlight, так как вопрос больше о архитектуре чем конкретно об этих техноглогиях |
| Автор: Gvozdin 21.12.2011, 16:51 |
| В общем все так, уровень данных(linq to sql), потом уровень бизнес логики. А вот PersonViewModel чем собственно занимается? На практике мы создаём контроллеры для отдельных сущностей или же чаще для отдельных бизнес процессов(можно читать контролов), которые и реализуют бизнес логику и все что надо для WPF. Далее уже идет смешанный режим работы в зависимости от ситуации. Либо работаем через наш ORM, загружая, изменяя и сохраняя данные. Либо же вызываем сервисные методы которые реализуют бизнес логику. Слой доступа к данным генерируется сам. Если на стороне сервисов нужен класс реализующий бизнес логику - то его надо сделать. Если на стороне клиента нужен класс реализующий бизнес логику - то его тоже надо сделать. Если есть требования по четкому разделению слоёв или это что-то дает, то вполне можно это все реализовать. |
| Автор: GRemlin87 21.12.2011, 17:11 |
| ViewModel хранит логику для представления например какой элемент в данный момент выделен ну и реализует интерфейс INotifyPropertyChanged, это по шаблону mvvm, ну в общем спасибо за то что разрешили мои сомнения по поводу моего подхода. Ещё бы кто помог ссылками на реальные проекты.. |