DDD: все должно вписаться или в Объект Объекта или Значения?
Нет никакого стандарта SQL для этого.
Однако С генерацией кода (или по требованию поскольку таблицы составлены или изменены или во времени выполнения), можно сделать это довольно легко:
CREATE TABLE [dbo].[stackoverflow_329931_a](
[id] [int] IDENTITY(1,1) NOT NULL,
[col2] [nchar](10) NULL,
[col3] [nchar](10) NULL,
[col4] [nchar](10) NULL,
CONSTRAINT [PK_stackoverflow_329931_a] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[stackoverflow_329931_b](
[id] [int] IDENTITY(1,1) NOT NULL,
[col2] [nchar](10) NULL,
[col3] [nchar](10) NULL,
[col4] [nchar](10) NULL,
CONSTRAINT [PK_stackoverflow_329931_b] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
DECLARE @table1_name AS varchar(255)
DECLARE @table1_prefix AS varchar(255)
DECLARE @table2_name AS varchar(255)
DECLARE @table2_prefix AS varchar(255)
DECLARE @join_condition AS varchar(255)
SET @table1_name = 'stackoverflow_329931_a'
SET @table1_prefix = 'a_'
SET @table2_name = 'stackoverflow_329931_b'
SET @table2_prefix = 'b_'
SET @join_condition = 'a.[id] = b.[id]'
DECLARE @CRLF AS varchar(2)
SET @CRLF = CHAR(13) + CHAR(10)
DECLARE @a_columnlist AS varchar(MAX)
DECLARE @b_columnlist AS varchar(MAX)
DECLARE @sql AS varchar(MAX)
SELECT @a_columnlist = COALESCE(@a_columnlist + @CRLF + ',', '') + 'a.[' + COLUMN_NAME + '] AS [' + @table1_prefix + COLUMN_NAME + ']'
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = @table1_name
ORDER BY ORDINAL_POSITION
SELECT @b_columnlist = COALESCE(@b_columnlist + @CRLF + ',', '') + 'b.[' + COLUMN_NAME + '] AS [' + @table2_prefix + COLUMN_NAME + ']'
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = @table2_name
ORDER BY ORDINAL_POSITION
SET @sql = 'SELECT ' + @a_columnlist + '
,' + @b_columnlist + '
FROM [' + @table1_name + '] AS a
INNER JOIN [' + @table2_name + '] AS b
ON (' + @join_condition + ')'
PRINT @sql
-- EXEC (@sql)
7 ответов
Вот мои два цента. Краткий ответ: UserPreferenceInfo - это объект значения, потому что он описывает характеристики объекта. Это не сущность, потому что нет необходимости отслеживать экземпляр объекта во времени.
Более длинный ответ: объект с более чем 100 не связанными друг с другом свойствами не очень похож на DDD. Попытайтесь сгруппировать связанные свойства вместе, чтобы сформировать новые ВО, иначе вы также можете обнаружить новые сущности.
Другой запах DDD - это, во-первых, наличие множества заданных свойств. Постарайтесь найти суть действия, а не только устанавливать значение. Пример:
// not ddd
employee.Salary = newSalary;
// more ddd
employee.GiveRaise(newSalary);
С другой стороны, у вас вполне могут быть законные причины иметь набор свойств, которые являются не более чем геттерами и сеттерами. Но тогда, вероятно, есть более простые методы, чем DDD, для решения проблемы. Там'
I'd say a UserPreferenceInfo is actually a part of the User aggregate root. It should be the responsibility of the UserRepository to persist the User Aggregate Root.
Value objects only need to be newed up (in your object model) when their values are shared. A sample scenario for that would be if you check for a similar UserPreferenceInfo and associate the User with that instead of Inserting a new one everytime. Sharing Value Objects make sense if value object tables would get to large and raise speed/storage concerns. The price for sharing is paid on Insert. Разумно абстрагировать эту процедуру в DAL.
Если вы не ограничиваете объекты значений, нет ничего против обновления.
Насколько я понимаю, UserPreferenceInfo является частью объекта User . Пользовательский объект Ergo - это совокупный корень, который извлекается или сохраняется с использованием UserRepository в целом, вместе с UserPreferenceInfo и другими объектами.
Лично я считаю, что UserPreferenceInfo является типом объекта, поскольку он имеет идентичность - его можно изменять, сохранять и извлекать из репозитория и при этом рассматривать как тот же объект (т. Е. С идентичностью). Но это зависит от того, как вы его используете.
ИМХО, не имеет значения, как объект представлен в DAL - хранится ли он в отдельной таблице или в части другой таблицы. Одним из преимуществ DDD является игнорирование настойчивости, и это обычно хорошо.
Конечно, я могу ошибаться, я тоже новичок в DDD.
100 properties sounds like a lot.
Try breaking UserPreferenceInfo up into smaller (more cohesive) types, which likely/hopefully are manageable as VOs.
Ответ 1 (практический)
Я большой сторонник DDD, но не форсируйте его. Вы уже поняли, что неизменяемые ВО добавляют больше работы, чем требуется. DDD спроектирован так, чтобы обуздать сложность, но в этом случае сложно управлять.
Я бы просто рассматривал UserPreferencesInfo как Entity и ссылался на него из ] Пользователь агрегат. Независимо от того, храните ли вы его как компонент или в отдельной таблице, это ваш выбор.
ИМХО, весь спор Entity vs VO может быть спорным. Маловероятно, что через 6 месяцев другой разработчик взглянет на ваш код и скажет: « WTF! Он не использует неизменяемые ВО! Какого черта он думал !! ».
Ответ 2 (пурист DDD)
Действительно ли UserPreferencesInfo является частью бизнес-домена? Другие упомянули о разрушении этого объекта. Но если вы придерживаетесь чистого DDD, вам может потребоваться определить, какие предпочтения принадлежат какому ограниченному контексту .
Это, в свою очередь, может привести к добавлению уровней обслуживания , и прежде чем вы узнаете это, вы перестроили решение очень простой проблемы ...
Вопрос в том, что это за объект UserPreferencesInfo?
Я не знаю, как NHibernate поддерживает этот случай, но некоторые ORM поддерживают специальные концепции для них. Например, DataObjects.Net включает концепцию Структуры . Похоже, в NH нужно что-то подобное.
Впервые в блоге. Надеюсь, я все сделаю правильно.
В любом случае, поскольку вы не показали нам объект UserPreferencesInfo, я не уверен, как он сконструирован так, чтобы в нем могло быть переменное количество вещей.
Если бы это был я, Я бы сделал один класс с именем UserPreference с идентификатором, идентификатором пользователя, ключом, значением, типом отображения и любыми другими полями, которые могут вам понадобиться. Это сущность. у него есть идентификатор и он привязан к определенному пользователю.
Затем в вашем пользовательском объекте (я предполагаю, что корень) имейте ISet.