Модель, бизнес-правила и постоянство

Question

У меня проблемы с поиском наилучшего подхода для определенного приложения.Я не очень привык к новым архитектурам, которые заменили старую TLA (трехуровневую архитектуру), поэтому я и пришел туда.

При проектировании Model и DAL для моего приложения (классы POCO, верно ??) у меня возникли следующие сомнения:

1. Должны ли мои классы Model только предоставлять свойства и реализовывать проверки правил? Несколько лет назад я реализовал классы, аналогичные реальному миру, поэтому, если бы у меня был Человек , который мог бы Ходить , я бы создал такой метод.Теперь каждый проверяемый образец (MVC, MVVM и т. Д.) Имеет «тупые классы», которые предоставляют данные и, при необходимости, проверяют эти данные.Как насчет сложных операций?Если они каким-то образом станут частью ВМ (я сомневаюсь, что это правильно ...).

2. При использовании LINQ to SQL в качестве преобразователя ORM, я должен выставить вмодель все атрибуты сущности? Например, большинство моих сущностей имеют столбец идентификатора в качестве своего первичного ключа.Это не должно беспокоить модель или бизнес, просто подробности реализации моей схемы базы данных.

3. Если (1) и (2) имеют значение false, то модель должен предоставлять сложные операции над классами, и не все атрибуты сущностей должны быть доступны, как мне создавать классы модели, используя LINQ to SQL и sqlmetal? Я видел некоторые примеры, которые используют частичныеклассы для расширения функциональности сущностей схемы, но это приведет к раскрытию деталей сущности (поскольку это просто расширение).

4. Если (2) ложно, чтосамый правильный способ использования sqlmetal и LINQ в качестве ORM? Я использую sqlmetal для извлечения схемы, LINQ для выбора сущностей, и что дальше?Создавать новые объекты на основе того, что у меня есть в базе данных?

5. В своих исследованиях я обнаружил, что ВМ из MVVM и P из MVP несколько похожи.Каковы обязанности Presenter ?И те из ViewModel ? Я фокусируюсь на этих двух шаблонах, потому что они полностью изолируют View от модели, аспект, который я предпочитаю.

6. Какие существуют методологии при разработке таких приложений [MVVM, MVP]? Должен ли я начать думать о модели, затем о слое {P, VM}, а затем о представлении?Это более субъективный вопрос, я знаю, но примеры были бы хорошими.

Я надеюсь, что смог сделать вопросы достаточно объективными.Я добавил объяснения к своим сомнениям, чтобы упростить ответ, но боюсь, что это сделало сообщение немного большим.В любом случае, большое спасибо за чтение, любые предложения приветствуются.

Answer 1

Вот несколько мыслей о дизайне модели из моего опыта.

1. Расслабьтесь. Независимо от того, что вы делаете в дизайне вашей модели, она все равно может быть открыта для критикии жалобы от людей.Вы не можете угодить всем.Если вы сделаете это полностью модным словом, совместимым с последним мышлением вещей, оно может быть сложным, абстрактным или трудным для понимания.С другой стороны, если вы просто соберете это без особой рифмы или причины, вы тоже можете попасть в неприятности.Код предназначен для обслуживания приложения, он предназначен для того, чтобы приложение попадало в готовую корзину таким образом, чтобы его было легко прочитать, легко понять, легко обслуживать.Многие другие соображения второстепенны.
2. Какой уровень воздействия делать .Правильный ответ зависит от того, каково будущее вашего приложения, и любой подход может быть хорошим решением.Что-то, что помогает мне решить, что делать с моделями, это притвориться, что я пишу более одного слоя потребителя / пользователя / пользовательского интерфейса, который идет поверх моделей.Поэтому обычно приложение имеет только один пользовательский интерфейс.Но представьте, что в приложении будет более одного пользовательского интерфейса - скажем, как веб-интерфейс, так и настоящий графический интерфейс смартфона.Делая вид, что будет и то, и другое, вы сможете принимать решения о том, чтобы все больше и больше логики добавлялось к уровню моделей / доступа к данным, и все меньше и меньше логики - на уровне пользовательского интерфейса.Если вы сделаете свои модели очень тонкими и выставите аспекты ORM в пользовательский интерфейс, то у вас возникнет соблазн вставить в интерфейс достаточное количество кода типа ORM.Это может привести к тому, что код станет более шизофреничным.Это делает его таким, что если вы когда-нибудь решите изменить бэкенды, скажем, с SQL на другой вариант SQL, или Cassandra, или что-то еще, вы в значительной степени не сможете этого сделать.ваш доступ к данным. Вы можете поместить весь свой доступ к данным в веб-сервис.Тогда ваш уровень пользовательского интерфейса будет использовать веб-сервис для доступа ко всем данным, как для чтения, так и для записи.Это звучит немного радикально, но имеет ряд ключевых преимуществ.
   • Он помогает разделить проблемы уровня пользовательского интерфейса и уровня бизнес-логики.
   • Позволяет добавлять дополнительные типы пользовательских интерфейсов позже при сравнительно небольших усилиях.Вы можете встроить инструменты в свою платформу (если они еще не существуют), что делает это очень легким, и вы можете обнаружить, что ваш код становится меньше.
   • Это делает его более сравнительно простым, чтобы полностью изменить то, как ваш бэкэндработает без изменения какого-либо кода вашего пользовательского интерфейса.

Таким образом я переместил приложение из SQL в Cassandra.Разделяя весь доступ к данным в веб-сервис, реализуя хороший набор тестов для веб-сервиса, затем повторно внедряя веб-сервис.После этого приложение стало намного меньше и чище.

Я думаю, вы беспокоитесь о неправильных вещах.Представьте, что уровень / модели доступа к данным предоставляют идеальные услуги, которые сделают ваши пользовательские интерфейсы максимально простыми для реализации.Представьте, как будет выглядеть этот идеальный слой доступа к данным, чтобы сделать работу проще.Остановите этот интерфейс, а затем воплотите его в жизнь.Как это выглядит изнутри, менее важно.

Важно то, что приложение должно быть завершено, оно должно работать, и оно должно быть читабельным и простым в обслуживании.Лично я бы не потел все остальное.Если ключевым требованием вашего приложения является то, что оно производит впечатление на человека, если смотреть изнутри, вы беспокоитесь о неправильных вещах.Прочитайте, что другие люди говорят, и используйте то, что резонирует в вас и имеет смысл, но не переживайте, если то, что вы читаете, не кажется вам полезным в ваших проектах.

Answer 2

Из своего опыта я узнал, что модели могут быстро устареть, особенно с увеличением детализации и сложности. Более того, слишком большое внимание к разработке детальных артефактов моделирования может отвлечь команду от предоставления дополнительных преимуществ своим клиентам. Поэтому я рекомендую вам рассмотреть гибкий подход к созданию моделей, который предоставляет достаточно подробную информацию для группы, чтобы они могли предоставлять ценные функции вашим клиентам в течение итерации в течение 2-4 недель. Взгляните на методологию Скотта Амблера Agile Model Driven Development (AMDD) .