Существует множество преимуществ использования платформы .NET Core, и мы изучаем их, чтобы увидеть, следует ли/когда мы должны перенести наши приложения.Архитектура в мире .NET Core
Одна из действительно привлекательных философий в .NET Core - это использование только компонентов платформы .NET, которые требуются, загружая эти через пакеты Nuget.
Если мы переместились, то мне бы очень хотелось, чтобы наши собственные фреймворки отразили неприметность подхода .NET Core. В настоящее время он больше связан с полным рамочным подходом .NET, где мы загружаем довольно «толстые» DLL. Я не видел конкретных советов о том, как лучше всего архивировать приложение, обращаясь к .NET Core, поэтому я советую здесь.
Для простоты давайте представим себе, что у нас есть только два приложения: App-A и App-B.
Оба приложения должны получить доступ к данным, хранящимся в SQL, к которым обращаются хранимые процедуры. App-A отличается от App-B, но они связаны друг с другом, поэтому вы можете себе представить, что некоторые хранимые процедуры вызываются только приложением App-A, некоторые только App-B, а некоторые вызываются обоими.
Весь код, который вызывает эти хранимые процедуры, хранится в общей DLL, называемой «SQL-DLL». Да, DLL предоставляет интерфейсы, специфичные для App-A и App-B, но DLL по-прежнему содержит ВСЕ код и поэтому может считаться «жирным», а не «худым».
Для всего 2 приложений можно было бы разделить это на 3 библиотеки DLL: один, содержащий вызовы для App-A, один для вызовов App-B и один для всех обычных вызовов. Но что, если у вас есть (скажем) 10 приложений? Перестановки становятся намного выше, и вскоре становится неясным, какие вызовы существуют в DLL.
Лучше, возможно, разбить DLL на более мелкие функциональные DLL - немного похоже на «микро-услуги»? Одна DLL для всех деталей Клиента, одна DLL для всех деталей заказа, одна DLL для всех .... но опять же, «GetCustomerOrders» принадлежит Клиенту или Заказу? Хммм.
Если у кого-то есть хороший совет по сохранению кода для мира .NET Core, то, пожалуйста, дайте мне знать.
Кроме того, у нас есть одно решение Visual Studio для каждого приложения, и каждое решение имеет общие проекты. Некоторые люди рекомендуют иметь разделяемые библиотеки как пакеты Nuget, а не проекты, но я думаю, что это усложняло бы отладку и TDD. Мысли об этом?
И, наконец, как лучше всего организовать это в исходном репозитории (например, TFS). В настоящее время общие проекты приводят к относительным путям, которые содержат множество «../../», которые отлично работают в Visual Studio, но могут вызывать проблемы на сервере сборки, когда пакеты Nuget не соответствуют ожидаемым путям.
Я знаю, что я много просил здесь, но любые/все рекомендации были бы очень признательны!
Очень основанный на мнениях вопрос, как вы здесь ... Вы не должны делать это с разбиением на сборки. Посмотрите на «Ограниченный контекст» из DDD, чтобы дать вам представление о том, когда и когда не нужно разделить модели на разные ограниченные контексты, например, взгляд Мартина Фаулера на ограниченный контекст, найденный здесь http://martinfowler.com/bliki/BoundedContext.html – Tseng
Привет Цзэн. Наверное, я пытаюсь выяснить, не отличается ли дизайн приложения .NET CORE от дизайна полноценного приложения .NET. В некотором смысле, было бы позором сидеть «жирное» приложение поверх рамки, которая была преднамеренно разработана, чтобы быть как можно более «худой». – DrGriff
Это не зависит от рассматриваемой структуры. Было возможно написать приложение с четким и модульным интерфейсом перед .NET Core и будет таким в будущем. Единственная разница теперь, Framework является модульной и автономной (возможно запустить несколько версий бок о бок) по умолчанию. При создании приложения ничего не меняется – Tseng