Комментарии 15
Откройте настройки в студии. Там их много но они разбиты на группы и ориентироваться проще. В коде их тоже можно разбить на классы
Попробуйте поискать в коде запахи и расправиться с ними по рецептам
Изучите c#. Например, null coalescing operators имели бы вам убрать один if из кода
Почитайте что-нибудь про дизайн. Ddd, mvc, mvvm
Откройте настройки в студии. Там их много но они разбиты на группы и ориентироваться проще. В коде их тоже можно разбить на классы
Я думаю, что разбить настройки по группам и классам не сильно решает проблему, оно только ее оттягивает дальше.
Попробуйте поискать в коде запахи и расправиться с ними по рецептам
За это спасибо, посмотрю.
Изучите c#. Например, null coalescing operators имели бы вам убрать один if из кода
В null coalescing operator выглядит он так себе. Он не отделяет блок {}, как if. Это еще хуже. Использую его только по назначению. А заменить if null coalescing операторами — это только вред
Почитайте что-нибудь про дизайн. Ddd, mvc, mvvm
Сейчас как раз уже начинаю читать книги, статьи.
Ну, вообще говоря, чтение книг — это чуть ли не единственный реальный способ чему-то научиться (кроме способа набить все шишки самому на своем опыте, конечно). То факт, что вы уже умеете писать программы, совершенно не означает, что вы умеете проектировать хорошую архитектуру — тем более на все случаи жизни.
Как ниже уже резонно замечено, нет никакой серебряной пули, или универсального решения на все случаи жизни. Есть разные способы для решения разных проблем. То что вы описываете — по сути проблема «как построить универсальный софт, чтобы он решал разные задачи». Ну или хотя бы адаптировался легче. На эту тему написаны десятки книг. Куча аббревиатур, самая известная из которых наверное SOLID — они все про это же, как писать софт, чтобы не было больно потом его развивать. Разве вы не этого хотите?
Только лучше сразу понимать: то что описано в книгах на эту тему — это тоже по большей части не готовые решения. Это инструменты. Их тоже можно применять не по делу, или неверно. Ими тоже нужно уметь владеть, чтобы не завинчивать гвозди отверткой.
Тут есть два пути - SAAS решение, где делается максимально универсально и никаких доработок под клиента не делается (только фичи которые нужны всем). Да, никаких полей в отчете в красный цвет пока потребитель сам в конструкторе отчетов не сможет красить поля самостоятельно.
Либо делается инсталляция максимально заточенная под клиента. Но тогда тут нужно минимум абстракций. Если что-то можно сделать хардкодом - делаем хардкодом.
Можно конечно делать нечто среднее - универсальное ядро системы с базовым функционалом которое бранчуется под каждого клиента, но тут велика вероятность, что ветки разойдутся и поддерживать зоопарк версий будет очень больно.
Много всего написали уже правильного, подскажу ещё как мы решали схожие проблемы.
Сталкивались с такой проблемой разработки под нескольких клиентов. Тоже изначально был путь отдельных настроек. Но тестировать и сопровождать при таком подходе очень больно. Пришли к решению через паттерн "стратегия". На этапе запуска приложения регистрируем необходимые реализации, при этом настройка только одна - "имя" клиента. Если инстанс приложения один под несколько клиентов разом, то можно реализации подхватывать во время запроса, в зависимости от того, от кого он прилетел.
По умолчанию можно делать дефолтную реализацию, которая подхватывается, если нет специфичной для клиента.
Таким образом все различающиеся части приложения можно выделять в отдельные кусочки и прятать за абстракцией. Отдельные реализации легко тестить. При тестировании внешних компонентов можно легко мокать или тестить целый контур с отдельной реализацией. Из минусов - абстракции усложняют код, но это гораздо удобнее кучи if'ов.
Я думаю, что такая проблема возникает у многих. Как ее решить, вот в чем вопрос?
А нету общего решения.
Скажем, для внешнего вида решение — это скины и, когда их не хватает, шаблоны. А для поведения — стратегии. А для чего-то — "просто" настройки.
Или, если проекты сильно различаются, то общее ядро, которое протаскивается во все проекты как пакет, и дальше в каждом проекте свои доработки в точках расширения.
А общего универсального решения нет, надо на каждый конкретный случай смотреть.
Мне кажется что проблема возникает из-за смешения уровней работы с данными и представления
Тут правда несколько случаев, это может быть несколько "типовых" продуктов, с разным UI, потому что потребности ларька и потребности сети магазинов разные.
Дальше можно сделать общий core, может быть какие-то общие функции и кастомные варианты сайтов для каждого из типов клиентов. Тогда у вас получается полный контроль над UI каждого типа + хорошо протестированная база.
А UI лучше всего сегментировать на основе уже существующей базы клиентов. Может быть там 2 или 3 типа клиентов оказаться.
Вообще это достаточно частая ошибка начинающих - когда вместо разделения кода пытаются сделать один общий параметризованный.
И еще хорошо бы понять "какие клиенты точно не ваши", потому что универсальный комбайн всего, который бы подошел и ларьку у метро "ИП Смирнов" и сети Магнит - не сделать.
Если проект не большой, то решение довольно простое - разделение на базовое решение и клиента (платформа и расширения). Общий функционал становится базой продукта (вы переходите от проектальной разработки к продуктовой), а всё остальное пишется модулями под клиента (дополнениями). В вашем варианте создавать свой язык, конечно, не надо. Достаточно использовать DI. Инсталяция каждого клиента должна включать имплиментацию только этого клиента. Допустим с тем же Strategy, что рекомендовали выше.
А может, сделать под каждого клиента отдельную ветку на GitHub? От if-ов избавляться везде, где можно, общий код вынести в мастер-ветку...
Пишешь на сисетке? Умей в ООП. Там все ООП.
Всякие фабрики, синглтоны, фасады, мосты, модули, миксины, декораторы
А вообще я советую для освоения паттерн PIDOR( Presenter Interactor Decorator Object Router), хороший паттерн, меня коллеги даже в его честь назвали
Начнем! Вы уже, возможно, знаете меня
Ого, да это же тот самый! Оставь автограф!
P.S. Надеюсь в следующей статье количество фотографий с вами будет больше.
Твоя проблема мне не кажется - проблемой. Чтобы построить грамотную архитектуру и проектировать сущности в БД, другими словами сделать дата-дизайн, нужен опыт.
Сам проходил похожие этапы, в итоге написал себе удобную CMS, и теперь проект любой сложности мне кажется простым. Вообщем обращайся, я помогу тебе разобраться со стеком технологий и архитектурой в твоих приложения.
Я не могу спроектировать архитектуру своего интернет-магазина или как я пишу «под клиента»