Добрый день. Необходимо сделать расширяемое приложение используя много уровненную архитектуру. Приложение будет использовать ms sql и активно использовать хранимки. Технология MVC web api и внешка angular. Модель будут строится по базе используя ORM Entity.

Трехуровневая - база данных, вебсервер и клиент.

Или вам повычурнее надо?
Берете любую книгу по ASP.NET MVC, желательно поновее, и там есть даже пример, спортивный магазин. с Entity Framework c MS-SQLSERVER.
С хранимками сложнее. Точнее, нет никакой сложности из Entity Framework их дергать, но как-то ORM больше расчитаны на то, что программисты дауны в базах данных, и чтобы сами ORM генерировали запросы, код был весь на шарпе, и ни в коем случае не ранить нежную психику программиста кодом на SQL. ))

Но не запрещают и хранимки дергать.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Более конкретно спрошу. Есть инструмент ADO.NET Entity Data Model там автоматически создаётся модель и context. И потом на базе этого я делаю интерфейс  и на базе него делаю класс по интерфейсу. Пока писал кое что понял, но есть всё ровно не понятки. Как от кого что куда переводить. Чем их обеднять и как разделить на уровни. Хочу именно пример живой увидеть.

так не надо особо никакие уровни. Советую почитать книгу, например эту:
http://www.apress.com/9781430265290

там прямо есть раздел, прямо показано по шагам как сделать магазин.
Разница разве что в том, что там прямо на MVC и клиент пишется. Но это совсем не играет особой роли.

Там в принципе хорошо расписано как делать такие приложения.

Количество уровней, как что разводить, зависит от сложности приложения. Начнете из того, что в книге, далее увидите, может еще где уровень выделите. Вообще этим увлекаться очень не стоит. Суть более менее простая. Должна быть модель, представление и контроллер. И модель не должна знать о контроллере или о чем-то еще. Модель - это данные и их обработка. Программисты ошибаются жестко и поголовно, когда в модель не включают базу данных. База данных и СУБД - это часть модели, т.к. сервер баз данных разрабатывают для обработки данных, а не только для хранения. Я не предствляю, как это надо проглупить, чтобы поверить, что база данных только для хранения данных. (кто думает, что это так, должен быть честным самим с собой и пользоваться файлами, а не СУБД. Ведь не ее ж дело обрабатывать данные).

Но, тем не менее, программисты иногда (часто), разделяют еще слой данных от модели.  Как по моему, модель делится на две части - часть в базе данных, там в хранимках описываются массовая обработка информации. Часть на клиенте базы данных (апп-сервер, веб-сервер или как кто называет). То, что на клиенте, занимается тем, что неудобно на реляционках делать: ветвления, конечные автоматы.

Тут вы сами уже смотрите. Можно и разделить, вынести работу с базой через CRUD.
Использование Entity Framework в принципе позволяет на шарпе на linq описывать все нужные запросы. Тогда сбывается мечта программистов о якобы ничего не делающей СУБД и логике на шарпе.

Больше по большому счету слоев нет. Разве что на части начнет делиться модель, при росте сложности. Например, выделится слой для аутентификации, проверке прав, ролей пользователя.

Ну так сразу всё не опишешь, но и сложного ничего нет. Делайте, сами нащупаете. А в книге хороший старт

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

Для себя я сделал несколько выводов. Как минимум стоит отделить все что работает с базой данных и лучше это сделать в виде отдельного проекта(на выходе должна быть *.dll). Да это дополнительные усложнения на старте. Но в замен вы получаете более чистую логику работы с данными. Особенно если вы сделали правильно и вся эта библиотека это просто поставщик данных. Вам не надо будет размазывать вызовы хранимых процедур и прочие радости, и в будущем, если вы захотите изменить что-то то вы измените это независимо от логики приложения. по поводу обработки данных, никто не мешает делать это через этот же DL, дописав в нем методы для вызова хранимых процедур. Главный профит это именно управление сложностью проекта. когда у вас будет отдельная логика для работы с базой у вас будет более четкая и простая логика отображения этих данных. и да, я бы советовал отделить понятия ViewModel, от того что хранится в базе данных. они почти никогда не будут совпадать. смешение этих вещей отличный пример непонимания такой вещи, как сфера ответственности. Если вы это не разделите, то рано или поздно вы начнете подгонять базу под представление либо наоборот. а то это уже будет накладывать отпечаток на всю архитектуру в целом.

По поводу выделения BL, принцип такой же, отделяем логику представления от доменной области приложения. Профит, опять же, в уменьшении ответственности слоев. Если вам потребуется писать отдельный сервис для этого же проекта, то по сути, вам понадобится взять уже существующие BL+DL и над ними сделать новый слой представления, в виде вебсервиса или винсервиса или консольного приложения и etc. 

Склеивая все это в один слой, вы все это теряете, но выигрываете в скорости... на старте. в дальнейшем, если проект долгий, а не просто курсовая работа в универе, то вы можете потерять и в скорости разботки.

Насколько помню, там в примере так и было. А вообще, я не упрощаю. А не "не усложняю". Вы видите проблему там, где ее нет. Выделить в отдельный классы, которые были в другом проекте, это ну на полчаса работы максимум. Это не то, о чем стоит переживать.



Вы не читали видимо этот пример. Там всё правильно показано, никаких EF в контроллере. Там модель отдельно, контроллер отдельно, и даже показывают как покрывать юнит-тестами. Пишут, что TDD. Врут безбожно ))) В TDD тесты пишут до написания кода, который тестируют. Но в остальном книга вполне нормальные вещи прививает для новичка. Ну разве что в контроллере пользуют Repository, а не модель. Для простых проектов пойдет.

У вас страхи необоснованные о том, что может страшное случиться. У меня большой опыт в этой сфере, архитектура и разработка огромных проектов, до 100 000 строк кода. Сейчас, например, проект где-то такой же - веб апи, SQL-SERVER, хранимые процедуры. Вообще не парился нигде ни о чем, не планировал, не строил ничего хитрого, даже EF не использовал и никакие ORM. Просто там сложная логика с правами на каждое действие, ролями, что EF был бы для проекта тормозом. Но ничего, есть такие штуки - Expression Tree. За полдня пишется объект, который набивает любые списки из базы, еще немного, пишется автоматическое заполнение параметров хранимок и даже генератор SQL-кода пишется буквально за день (три страницы кода) для того, чтобы в шарпе можно было легко писать фильтр прямо в linq и он генерировал фильтр в SQL и выполнялся на стороне субд.

А всё просто, надо разрабатывать по
YAGNI

Смыл этого ягни: знать, как решаются проблемы полезно, но не надо планировать проблемы. Т.е. вы сейчас пребываете в страхе, что что-то недопланируете, потом будет хуже. Различные представления архитектуры, паттерны проектирования учат сразу проблеме и решению, которое получается В РЕЗУЛЬТАТЕ решения проблемы. И вы думаете, что научившись решениям типовых проблем вам надо на них закладываться. Так вот, планируя проблемы, вы их получаете.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Да, и кстати, дополню. То что я не планировал, совсем не значит, что у меня в коде хаос, всё в куче и ничего не разделено. Разделено и не хаос. Просто оно росло эволюционно. Я даже ключевые архитектурные вещи пишу только "по требованию", когда происходят уже проблемы (только начинают, два раза повторяются), а не планирую что они могут быть и не строю архитектуру в попытках всё предусмотреть

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

Если посмотреть на архитектуру чуть шире, чем просто на паттерны, то любое ваше решение, определяющее дальнейшее развитие вашего кода в проекте является решением, определяющим общую архитектуру. И количество строк тут совершенно не является критерием. И я не предлагаю сразу заворачивать все в паттерны по любому поводу. Даже наоборот. Но отделять и локализовывать разного рода зависимости будет хорошим решением в любом проекте, который планируется разрабатывать больше чем месяц. К примеру, очень часто вижу ситуацию, когда бизнес сущности используются в качестве ViewModel. в итоге когда наступает момент вывести на эту страницу чуть больше информации, начинаются придумывания велосипедов и подпорок, в виде разного рода хелперов и экстеншенов для бизнес объектов(наличие экстеншена на свой собственный класс в 95% случаев говорит о том, что ровную архитектуру уже прое...ли, и дальше пилят костыли, IMHO), хотя разделить это сразу ничего бы не стоило. В итоге срок внесения изменений растет либо растет технический долг, а разработчики, если не сильно дальновидные, все время думают, что у них все ОК. пока не приходит *опа.

Опять же, я только "за" итеративный подход. Я не предлагаю закрыться на месяц в кабинете и выдумывать суперскую архитектуру, вылизанную до предела. Просто есть вещи, от которых стоит отказаться почти сразу, что бы потом не было больно(при этом помним про размеры и длительность проекта). Эти вещи часто похожи на согласование по кодированию, в том плане, что никто не сомневается в том, что надо давать адекватные имена, и также никто не сомневается в принципе единой отвественности. Главное не забыть про то, что эти принципы есть. И, если не забывать об основных принципах, то архитектура уже будет достаточно ровной. Просто разделите ответственность.


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

К тому же, по теме, на такой общий вопрос, как у автора, можно ответить только общими замечаниями.

Если вы не итерационного подхода (эволюционного), то дальше дальше вопрос только в разных навыках работы с кодом.

Где стелить солому для падения заранее зависит от того, насколько привычно код менять и насколько быстро.
Это вопрос так же рефакторинга. Насколько часто он проводится. Юнит-тестов. Есть ли они, не вызывает ли дискомфорта мысль, что сейчас надо будет менять код, а можно что-то сломать и не заметить.

Можно *опы не опасаться и двигаться легко по направлению к ней, потому что как только она впереди замаячит, никто не мешает менять код. Если это постоянное и привычное дело, то не надо заранее от нее страховаться.

Рефакторинг - это как веник. Т.е. сделали какую-то работу, подмели. Если уборку не делать, то как не старайся в планировании, когда-то придется менять квартиру (ой, а не переписать бы всё с нуля).

Тут еще одна тонкая даже философская мысль. За кого болеть, за брата или за медведя. Люди, увлекающиеся паттернами и архитектурами, настаивают, что архитектуры должны быть разделены, гибкие, поддающиеся изменениям. Но если подумать, это противоположная цель по отношению к задаче. Задача требует делать жестко. Хотя бы потому, что программа, типы в ней, должны быть как рельсы для поезда, он должен жестко двигаться только в нужных направлениях, точно по выполнять требования, как можно жестче. В задаче никогда не стоит требование гибкости. Гибкость - это то, что додумывают себе сами программисты, якобы для того, чтобы успешно двигаться к цели и где-то не застрять.
Так вот YAGNI позволяет избавиться от этой дилеммы. Оно предлагает делать всегда жестко, а вместо гибкости использовать простоту. Т.е. чем проще код, тем легче его менять, потому что количество строк небольшое. Так же стремление к минимальности (DRY), заставляет чисто механически разделять и делать гибким решение. Но только по требованию. Т.е. когда уже начало что-то дублироваться, происходит вынесение кода в отдельный класс, в метод, скрывание за интерфейсом. Таким образом гибкость появляется естественным образом, без планировния.

Еще, YAGNI - это на самом деле не "непланирование". Это более формализированный способ работы. Особенно если с TDD. Т.е. поставил маленькую задачу, написал тест, написал код заведомо упрощенный, тесты прошли, порефакторил. Это аналогично, как если бы вы решали задачу, допустим по физике и использовали бумагу для записи. Т.е. у вас есть черновик, в котором вы записываете ход решения задачи. Вас космос и звезды не заставляют решить всю задачу в воображении, а потом записать только результат. Вы когда решаете задачу, даже в уме, вы где-то храните промежуточные результаты. Так вот, там никто не запрещает использовать ручку и бумагу.
В программировании же программисты почему-то стремятся решать всё именно в уме, а записывать всё сразу "правильно". YAGNI - это способ постепенного изложения мыслей на бумаге (в коде), возможность решать задачу кусками.


Этот ответ добавлен с нового Винграда - http://vingrad.com

Повторюсь. Мы говорим об одном и том же, только разными словами.
Давайте придем к общему знаменателю, и попробуем вернуться к теме топика.

Можно выделить следующие вещи:
1. итеративность
2. рефакторинг
3. "не хаос" - я рассматриваю это как цель рефакторинга
4. уменьшение сложности - опять же, это цель рефакторинга

Я думаю, что если вы работали в команде хотя бы 2-3 чел. над одним проектом, то рано или поздно возникали ситуации, когда приходилось садиться всем в митингрум и принимать решение о том, как делать похожие вещи. Это относится к очень большому кругу вещей в написании кода, начиная с соглашения по именованию и заканчивая приминениями(или НЕ применением, такое тоже бывает часто) разных паттернов.

Моя основная мысль, что о некоторых подобных вещах можно договориться "на берегу", т.е. пока не начали плыть(писать). Почему это полезно? Ну хотя бы по тому, что часто разные люди по разному воспринимают слова "разделено и не хаос" или "уменьшение сложности". И как следствие они будут по разному рефакторить код. В итоге мы получим в общем репозитории разные способы решения похожих задач, что плохо повлияет на "уменьшение сложности".
Я конечно же не отрицаю необходимости глобального рефакторинга, но первый этап рефакторинга должен быть выполнен тем кто раборал над фичей, и отрефакторить надо ДО комита в репозиторий. не обязательно рефакторить до какого то супер решения, но надо довести до того шаблона, который был принят на этом проекте.
Точно также я понимаю, что когда проект находится в зачаточном состоянии, то обычно никаких решений не принимается. Хотя бы по той причине, что никто из участников не представляет общий скоуп проблем и задач. Но, обычно через какое-то время, может через месяц, может два, люди начинают сталкиваться с необходимостью выработать какие-то решения. Это и будет архитектурными решениями.
Но, я не думаю, что если вы написали 10 проектов и в каждом у вас были одни и теже проблемы, которые приводили к одним и тем же решениям и к одному и тому же рефакторингу, то и 11 проект вы будете писать тупо в лоб, не думая о том, что бы решить эти проблемы сразу. Мы же должны учиться на ошибках? Мне кажется должны! )) вот и получится, что к началу очередного проекта у вас уже будут сложившиеся архитектурные паттерны, которые вы оттачивали на предыдущих проектах, и вполне логичным, было бы попытаться избажать этих проблем в новом проекте(Я сейчас говорю о совсем базовых решениях, типа разделить логику работы с базой от логики представления, а не о каких-то конкретных паттернах, которые могут неопдходить для разных проектов). И если вы не пытаетесь избежать проблем, с которыми вы сталкивались на каждом проекте, то это выглядит очень странно. Это как каждый раз наступать на одни и теже грабли. Ну рано или поздно надо бы научиться их обходить или хотя бы вовремя замечать!
Это, опять же, не запрещает решать проблему итеративно, можно хоть задом наперед, если сильно хочется ))). 

С разным работал количеством работал. 12 лет опыта, вполне приличного, в разных проектах, от разработки ИИ, математики, функционального одного языка, до энтерпрайза. Даже в геймдев раз занесло. Но наибольший и стабильный опыт (лет 8) - энтерпрайз.

Могу сказать, что и навыки даже сейчас улучшаются и отношение меняется к тому, как развивать проект. Было и такое как у вас. Но дальше с опытом уходит именно в сторону - решать в лоб, YAGNI, KISS, DRY. И становишься одиночкой, задалбывает работать в колективе и что-то кому-то объяснять, а они тащут вниз. Один человек может стоить команды, и 10 человек будут работать хуже, чем один.
Например, 4 месяца назад я пришел в проект, не справлялись. Сейчас я один на бекенде, скл-сервер. Поувольняли, сравнили производительность. Роберт Гласс в своей книге писал, что разница в производительности бывает составляет до 28 раз у программистов.

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

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

Это всё не формально происходит.

И нет, 10 раз если были те же проблемы, я не буду на них закладываться. Я просто буду про них помнить и если они замаячат, я быстрее поверну паруса.

Если часто делаешь рефакторинг, то происходит переоценка, что важно, а что нет. Вот подумайте, какую вы невообразимо сложную проблему решаете, вынеся код модели в отдельную сборку? У вас сборка используется в нескольких проектах? Я не отговариваю делать сразу в отдельной сборке. Но, на самом деле цена важности такого решения почти нулевая. Единственное, что у вас модель просто лежит на отдельной полочке и вы можете ею отдельно полюбоваться, а в отдельной папке в проекте видимо в лом.  

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

Этот ответ добавлен с нового Винграда - http://vingrad.com