Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Модели
|
|||
|---|---|---|---|
|
#18+
Добрый всем день. Изучаю ASP.NET MVC. С основами разобрался, теперь меня мучает вопрос как правильно архитектурно разделять между различными слоями модель данных? Для примера имеем следующую схему: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. стоит задача отобразить клиента с паспортными данными. Я так понимаю нужно написать модель которая будет представлять собой следующее: Вариант1: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. Вариант 2 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Вариант три: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Какой вариант правильный? возможно есть и другие способы о которых я не знаю, если подскажите буду благодарен. Так же интересует вопрос получения этих моделей: в контроллере ? написанием какого либо класса доступа к данным который одним методом вернет такую модель? или вообще вынести все в другую сборку и оперировать какими нибудь соглашениями (интерфейсами) или еще чем? Вопрос наследования сущностей - класс customer имеет поле тип, в дальнейшем предполагается наследовать от него три класса Person, Legal и Individual, к каждому классу добавится набор уникальных полей, а например для класса Legal будет задача отобразить клиента но вместо паспорта (его у него нет) показать данные ОГРН. Как в таком случае будет выглядеть слой достапу к данным? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2013, 17:11 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, если тебе нужно просто отобразить, можешь напрямую передавать во вью Customer и Document объекты. для целей создания и редактирования объектов тебе может понадобится CustomerModel и DocumentModel. в таком случае Вариант 2. и для маппинга тебе поможет Automapper: var model = Mapper.Map(customer, new CustomerModel()); и наоборот var customer = Mapper.Map(model, new Customer()); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2013, 17:35 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
hVosttevgen12345, если тебе нужно просто отобразить, можешь напрямую передавать во вью Customer и Document объекты. для целей создания и редактирования объектов тебе может понадобится CustomerModel и DocumentModel. в таком случае Вариант 2. и для маппинга тебе поможет Automapper: var model = Mapper.Map(customer, new CustomerModel()); и наоборот var customer = Mapper.Map(model, new Customer()); спасибо за оперативный ответ. Mapper я так понимаю писать нужно самому? А что с вопросами наследования и где должна находится логика получения данных - так как это только пример, в реальных более сложных ситуациях просто получать в контроллере сущьности не есть гут? Так же мне нравиться вариант 3 - он вообще живой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2013, 17:52 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, нет, маппер писать самому не надо. где-то при запуске приложения надо выполнить следующее: Mapper.CreateMap<Customer, CustomerModel>(); Mapper.CreateMap<CustomerModel, Customer>(); Mapper.CreateMap<Document, DocumentModel>(); Mapper.CreateMap<DocumentModel, Documetn>(); если нужны какие-то преобразования в логике маппинга, они здесь же конструируются, например: Mapper.CreateMap<CustomerModel, Customer>() .ForMember(x => x.Id, a => a.Ignore()); AutoMapper качается отсюда https://github.com/AutoMapper/AutoMapper или ставится через Nuget (предпочтительней) http://nuget.org/packages/automapper В 3 варианте: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2013, 18:00 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
hVostt, Большое спасибо! Значит третий вариант тоже живой? И можно его применять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2013, 19:10 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
Вопрос с наследованием и размещением логики так и не прояснился. Кто подскажет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 01:20 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345Вопрос с наследованием и размещением логики так и не прояснился. Нонче некто hVostt говорит, что наследование - зло, нужно юзать DI :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 09:08 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
МСУevgen12345Вопрос с наследованием и размещением логики так и не прояснился. Нонче некто hVostt говорит, что наследование - зло, нужно юзать DI :) И как этого зверя применить на текущем примере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 17:00 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345И как этого зверя применить на текущем примере? hVostt - это мембер, его нельзя применить на текущем примере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:13 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
МСУevgen12345И как этого зверя применить на текущем примере? hVostt - это мембер, его нельзя применить на текущем примере. я имел ввиду DI ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:35 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
Продолжу рассуждения. Логика получения данных из БД в контроллере - зло. Значит есть слой доступа к данным (где то там, например в отдельной сборке). Как правило такой слой содержит CRUD методы для сущностей. В моем понимании это методы: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Вопрос - должен ли слой доступа к данным содержать метод Код: c# 1. ? Если нет, то где располагается логика получения этой модели? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 01:17 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, что то не могу понять потуга.. public CustomerModel GetCustomerModelById(long id) {....} Вы наверное это имели в виду public T GetCustomerModelById<T>(Object key) {....} ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 01:22 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, то, что ты написал, это слой датасервиса (репозитория), в нем нечего делать моделям представления. Для маппинга модели данных на модель представления импользуй маппер. Маппить должен контроолер - дергать репозиторий, результат намапливать на вью модель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 14:47 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
Где-то в степиevgen12345, что то не могу понять потуга.. public CustomerModel GetCustomerModelById(long id) {....} Вы наверное это имели в виду public T GetCustomerModelById<T>(Object key) {....} Потуг простой - хочу понять архитектуру или концепцию построения приложений на ASP.NET MVC. Просто до этого я не занимался созданием веб приложений и пока изучаю для себя, но впереди есть перспектива принять участие в интересном мне проекте, вот и разбираюсь. Мне не понятно где должна быть логика склеивания модели в модель-вью? С одной стороны у меня есть репозиторий который мне вернет клиента, потом мне нужно сходить за документами (другой репозиторий) и дополнить модель-вью паспортом - так? С другой стороны эти лишние походы в базу не оптимальны и что мешает получить сразу необходимые данные - но тогда репозиторий должен мне предоставить зоопарк методов для каждой вью модели? Или репозиторий должен быть для модель-вью? Пример . от customer получим два наследника Legal и Person у них добавятся уникальные поля. Необходимо отображать список всех клиентов или результат поиска по имени в виде: Код: c# 1. где документ это серия и номер паспорта для Person или другого документа удостоверяющего личность, а для Legal это номер и дата выдачи свидетельства о регистрации (ОГРН). Если решать задачу в лоб то не проблема - создам соответствующую модель-вью и в документ буду записывать данные в зависимости от типа клиента (тип клиента служебное поле). Но как это спроектировать правильно? где должна быть эта логика и как будет выглядеть депозиторий в этом случае? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2013, 21:58 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, если модель включает много сущностей, зараяжайте модель в момент создания инжектировав в нею - что там у вас -тип клиента если у вас как вы говорите получается зоопарк методов, а оно вам надо, можно применить "композицию" в модели - мувице это поддерживает, тогда весь репозитарий сведется к классическому виду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2013, 22:54 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, вот примерно Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. И нужен ли тут репозитарий...... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2013, 23:05 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
Где-то в степиevgen12345, вот примерно Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. И нужен ли тут репозитарий...... Вот я и пытаюсь понять - нужен ли репозиторий и собственно DI. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2013, 23:12 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
evgen12345, да как бы надо смотреть на комплексно, в данном случае не вижу смысла, контейнер тоже смотреть комплексно, или как старший скажет. ведь код по созданию объекта модели в контроллере в любом случае придется писать, сам объект от святого духа не возьмется в данном случае у вас просто CustomerModel cm=new CustomerModel(тип клиента) а с контейнором вам придется прицеплять контейнер к проекту, заряжать его типами, и при вызове резолве все равно запихивать туда тип клиента ( или при зарядке), из за одного инжекта тащить di ? Можете сами написать di, это не сложно, создается делегат грубо говоря под каждый тип при зарядке, а потом в коде вызывается этот делегат в зависимости от типа , этот кусок кода исполняется и выплевывается готовый объект. Шаманства никакого, трюк давно известный.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2013, 23:39 |
|
||
|
Модели
|
|||
|---|---|---|---|
|
#18+
Где-то в степиevgen12345, да как бы надо смотреть на комплексно, в данном случае не вижу смысла, контейнер тоже смотреть комплексно, или как старший скажет. ведь код по созданию объекта модели в контроллере в любом случае придется писать, сам объект от святого духа не возьмется в данном случае у вас просто CustomerModel cm=new CustomerModel(тип клиента) а с контейнором вам придется прицеплять контейнер к проекту, заряжать его типами, и при вызове резолве все равно запихивать туда тип клиента ( или при зарядке), из за одного инжекта тащить di ? Можете сами написать di, это не сложно, создается делегат грубо говоря под каждый тип при зарядке, а потом в коде вызывается этот делегат в зависимости от типа , этот кусок кода исполняется и выплевывается готовый объект. Шаманства никакого, трюк давно известный.. Это всего лишь пример который я придумал. Писать самому di смысла не вижу, если только ради интереса - но мой интерес сейчас ASP.NET MVC по этому при необходимости воспользуюсь готовыми реализациями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2013, 08:15 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38230122&tid=1358539]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 318ms |

| 0 / 0 |
