почему мое разделение проблем База данных/Бизнес сервис objects/Web, заставляет меня написать больше кода?

Поддерживаемое приложение - это приложение с низкими затратами на обслуживание. Если общие изменения занимают много времени, значит, это не поддерживаемое приложение.

Ключевой вопрос, который следует задать, - насколько распространены запросы функций по сравнению с технологическими изменениями.

Если вы меняете предпочтительный набор технологий каждые 3 месяца или около того, у вас никогда не будет времени на внедрение новых функций, поэтому ваша архитектура будет оптимальной ...

У меня тоже есть такой же опыт, многое из того, что я узнал в школе об абстракции и разделении "вещей", на самом деле делает мой код все более и более сложным.

Я пришел к поймите, что когда у вас высокая сплоченность (ваши классы очень маленькие и очень точные), у вас будет высокая связь. При дальнейшем упрощении каждого отдельного класса каждый компонент сам по себе будет все более и более бесполезным; чтобы получить простую функциональность, вам нужно управлять сложными взаимодействиями между этими простыми «связными» объектами.

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

В Python это очень просто:

for line in open("filename"):
    # do something with line

Я '

При разработке приложения уровни абстракции должны предоставлять ценность. Их не должно быть там только потому, что это «лучшая практика». Некоторые приложения имеют богатую модель предметной области и используют уровни абстракции. Однако приложение, которое очень ориентировано на данные без особой логики, может не иметь потребности в таком количестве уровней.

Я видел некоторые приложения, которые определяют несколько уровней, соответствующих каждому объекту, с именами, послушно соответствующими слою EmployeeDL, EmployeeBL, EmployeeUL . Ни один из объектов не добавлял никакого значения и просто передавал значения между слоями из пользовательского интерфейса в базу данных. Это было бессмысленно.

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

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

Смысл разделения этих вещей в том, что

• один разработчик работает над одной частью
• каждая часть может быть более легко протестирована на единицу

Если у вас нет 8 разработчиков (чтобы соответствовать вашим восьми -piece pie) и пишут код unit-test, чтобы он соответствовал производственному коду, ваша договоренность избыточна.

It is about the upfront investment. The time it takes to build something correctly will always be greater than the time it takes to build something that just works. One important takeaway from DDD is that you can abstract out a lot of the plumbing and put it towards a development framework that can be reused, so that you don't have as high of an initial investment on other projects. You can abstract the bases for your repository, unit of work, domain object, etc. Additionally, you can take the actual database functionality and implement them as a provider, so that you write once and chose the correct one for the job next time, or if you need to change the backing store for your domain object.

A solution that has properly addressed its seperations of concern has some very productive features - such as it being highly testable, more apt to be scalable, more reusable, easier to debug, easier to modify, and easier to extend. Being able to see how the domain flows through the code is a total rush, and being able to describe a concept to a stakeholder, or walk them through the concept that a code artifact is executing is worth its weight in gold.

With my developers, I had a very hard time selling the concepts of SOC, and DDD for that matter, at first. Apart from the testability, ease of debugging, and a unified language between technical resources and stakeholders, a lot of the benifits either come after the initial deployment, or not at all. For example, you might not need to scale out (for example, wrapping a facade around your services and putting them on another server to host a REST-ful API through web services), but knowing that you can is a really, really great feeling.

I understand your fear of the ripple effect. To be honest, there is always going to be a ripple of some sort. With a properly designed repository, you can isolate the size of the ripple to be just a few places, though. Since it appears that you are using .NET (based on the WPF comment), you might want to take a look at .NET Domain-Driven Design with C#: Problem - Design - Solution. While I do not agree with 100% of the implementation in the sample, it really does illustrate how well this approach can really work.

You are definitely writing too much code. Adding a single field shouldn't be a 8 step process.

1. Why not use NHibernate? You cans till have your true domain model and the "database translator" is (now) a simple exercise with FluentNHibernate.

2. There are some very robust frameworks out there for combining steps 4-6 in a relatively transparent way. WCF (the horror!) for one.

Какие инструменты вы используете? Я никогда не слышал о таком высоком уровне неавтоматизированной чепухи. Я почти не верю, что твой вопрос правдив. А что вы делаете с «бизнес-объектом» на клиенте?

Вы говорите о соединении уровней доступа к данным, бизнеса и веб-сервисов. Это именно то место, где нужно соединять , а не !

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

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

Будьте осторожны в своих просьбах!

Также рассмотрите возможность использования уровней абстракции, которые могут быть реализованы с простой передачей, но при необходимости переопределены.

Представления базы данных являются хорошим примером - у меня обычно есть только уровень приложения ссылаться на таблицы базы данных через представления (четко обозначенные суффиксом _v), а не напрямую через имена таблиц. Обычно они ссылаются на одну таблицу и представляют собой всего 2 строки DDL каждая. Его легко создать и легко поддерживать, но его также можно расширить, чтобы обеспечить перевод между приложением, или базой данных.

Другой пример - свойства в Python, где ваш код может напрямую ссылаться на переменные класса или экземпляра, а не всегда проходить через сеттеры и геттеры. Тогда позже, если вам нужно выполнить перевод между этой переменной внутри класса и кодом, который обращается к нему, вы можете определить функцию свойства, которая вызывается для доставки переменной. Это происходит прозрачно для вызывающей программы.

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