确定保存设置的责任(控制器、服务和映射器)
编辑:
因为我迟到了,才向 @arcain 授予 300
的初始赏金,所以我要重新开放。并将额外的 150
奖励给@arcain。当然,除非有人提供更好的答案。 :)
/编辑
考虑以下形式:
language | region | active | default |
-----------------------------------------------
en | GB | [x] | (*) | [X delete]
nl | NL | [x] | ( ) | [X delete]
nl | BE | [x] | ( ) | [X delete]
[x] let visitors browser-settings determine the default language
[save]
上表的设置将保存在数据库表中,其中的列映射到上面的列(显然不包括最后一列)。
所有(保存和删除)操作都直接到本地化控制器。 Localization 控制器基本上调用 LocalizationService 上的方法,如下所示:
$localizationService->updateCollection( $_POST ) // update collection settings
// or
$localizationService->delete( $_POST ) // delete a single locale
LocalizationService 依次调用 LocaleMapperDb,如下所示:
foreach( $localeCollection as $locale )
{
$localeMapperDb->update( LocaleModel $locale );
}
// or
$localeMapperDb->delete( LocaleModel $locale );
不过,保存此设置的责任是:
[x] let visitors browser-settings determine default language
它将保存在名为 site_settings 的数据库表中。我想到了几个选项:
- 在 LocalizationController 中使用 SiteService / SiteSettingsService。但是,完整的表单已在 LocalizationService 中生成并处理。
- 在 LocalizationService 中使用 SiteMapperDb / SiteSettingsMapperDb 并在 updateCollection( $_POST ) 中使用它
- 在 LocaleMapperDb 中使用 SiteMapperDb / SiteSettingsMapperDb
第一个和最后一个选项看起来是最糟糕的选项,但我不确定。您认为最好的选择是什么?或者也许你有其他选择,我没有想到?
EDIT:
Because I was to late with awarding the initial bounty of 300
to @arcain I'm reopening. And awarding the additional 150
to @arcain. Unless of course somebody provides even a better answer. :)
/ EDIT
Consider the following form:
language | region | active | default |
-----------------------------------------------
en | GB | [x] | (*) | [X delete]
nl | NL | [x] | ( ) | [X delete]
nl | BE | [x] | ( ) | [X delete]
[x] let visitors browser-settings determine the default language
[save]
The settings of the above table will be saved in a DB table which columns map to the above columns (excluding the last column obviously).
All (save & delete) actions direct to a Localization controller. The Localization controller basically calls methods on a LocalizationService, like so:
$localizationService->updateCollection( $_POST ) // update collection settings
// or
$localizationService->delete( $_POST ) // delete a single locale
The LocalizationService in it's turn calls a LocaleMapperDb, something like this:
foreach( $localeCollection as $locale )
{
$localeMapperDb->update( LocaleModel $locale );
}
// or
$localeMapperDb->delete( LocaleModel $locale );
Where though, is the responsibility for saving this setting:
[x] let visitors browser-settings determine default language
It will be saved in a DB table called site_settings. I have thought of a few options:
- Use a SiteService / SiteSettingsService in the LocalizationController. But then, the complete form is generated and processed in the LocalizationService already.
- Use a SiteMapperDb / SiteSettingsMapperDb in the LocalizationService and use it in updateCollection( $_POST )
- Use a SiteMapperDb / SiteSettingsMapperDb in the LocaleMapperDb
The first and last options look like the worst options, but I'm unsure. What do you feel is the best option? Or maybe you have an alternative option, I haven't thought of?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为在这种情况下将域模型对象投影到视图模型对象上效果很好。
对于所附代码(请原谅我用 C# 编写;它应该相当可移植),域模型对象永远不会公开(它们只能在服务对象中直接访问。)服务仅公开视图模型对象,就像 LocalViewModel 一样,这些视图模型对象由控制器操纵。
LocaleConfigController
还将服务返回的数据映射到LocaleConfigViewModel
对象,并且该对象是唯一与视图直接交换的对象。所以,简而言之,视图有一个专用的控制器,视图通过 LocaleConfigViewModel 对象与控制器通信。控制器操作
LocaleConfigViewModel
对象并调用ILocaleConfigService
和ISystemConfigService
的实现。服务对象从不将域模型暴露给控制器,它们负责将视图模型对象映射到域模型对象(通过任何需要的持久性机制)。请注意,区域设置服务是一个配置服务,它不会有任何实现来查找正确的本地化字符串是什么。我会将其放入另一个服务中,因为它可以用在您不想公开任何允许更改本地化配置的方法的地方。
例如,在应用程序的管理端,您可能需要本地化配置服务和本地化字符串呈现服务(因为管理站点也可以本地化)。对于面向客户的前端,您可能只需要本地化字符串渲染服务,因为系统配置修改应该是不需要的并且超出了该站点的范围。
所以,最后回答你的问题:控制器包含对区域设置和系统配置服务的引用,并且控制器专用于视图——它有一个定义良好的契约,其中只有
LocaleConfigViewModel
交换了。至于保存系统范围设置的责任所在,控制器负责从 LocaleConfigViewModel 中解压系统设置并将它们推送到适当的服务(在本例中为 ISystemConfigService< /code> 实例)它们将被持久化。
I think projecting domain model objects onto view model objects works well in this situation.
In the case of the attached code (please pardon me for writing it in C#; it should be fairly portable) the domain model objects are never exposed (they only are accessed directly within the service objects.) The services only expose view model objects, like
LocalViewModel
, and those view model objects are manipulated by the controllers.The
LocaleConfigController
also maps the data returned by the services into aLocaleConfigViewModel
object, and this object is the only object that is exchanged directly with the view.So, in a nutshell, the view has a dedicated controller, and the view communicates with the controller via the
LocaleConfigViewModel
object. The controller manipulates theLocaleConfigViewModel
object and calls into implementations of theILocaleConfigService
and theISystemConfigService
. The service objects never expose the domain model to the controller, and they are responsible for mapping view model objects to domain model objects (via whatever persistence mechanism is desirable.)Note that the locale service is a configuration service, it would not have any implementation to look up what the correct localized strings would be. I would put that into another service, because it could be used in places where you would not want to expose any methods that would allow the alteration of the localization config.
For example, in the management side of the application, you would want both the localization config service and localization string rendering service (since the management site could be localized as well.) For a customer facing front end, you would instead probably want only the localization string rendering service, because system configuration modifications should be unwanted and out of scope for that site.
So, to finally answer your question: the controller contains references to both the locale and system configuration services, and the controller is dedicated to the view -- it has a well-defined contract where only
LocaleConfigViewModel
s are exchanged.As for where the responsibility lies for saving the system-wide settings, the controller is responsible for unpacking the system settings from the
LocaleConfigViewModel
and pushing them into the appropriate services (in this case theISystemConfigService
instance) where they will be persisted.