我最近遇到了为我的wpf应用程序创建添加和编辑对话框的问题.
我想在代码中做的就是这样.(我主要使用viewmodel第一种方法与mvvm)
调用对话框窗口的ViewModel:
var result = this.uiDialogService.ShowDialog("Dialogwindow Title", dialogwindowVM);
// Do anything with the dialog result
它是如何工作的？
首先,我创建了一个对话服务:
public interface IUIWindowDialogService
{
bool? ShowDialog(string title, object datacontext);
}
public class WpfUIWindowDialogService : IUIWindowDialogService
{
public bool? ShowDialog(string title, object datacontext)
{
var win = new WindowDialog();
win.Title = title;
win.DataContext = datacontext;
return win.ShowDialog();
}
}
WindowDialog是一个特殊而简单的窗口.我需要它来保留我的内容:
<Window x:Class="WindowDialog"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
Title="WindowDialog"
WindowStyle="SingleBorderWindow"
WindowStartupLocation="CenterOwner" SizeToContent="WidthAndHeight">
<ContentPresenter x:Name="DialogPresenter" Content="{Binding .}">
</ContentPresenter>
</Window>
wpf中对话框的问题是dialogresult = true只能在代码中实现.这就是为什么我为我dialogviewmodel实现它的界面.
public class …我正在计划一些工作,将依赖注入引入当前的大型单片库,试图使库更容易进行单元测试,更容易理解,并可能更灵活地作为奖励.
我决定使用NInject,我真的很喜欢Nate的"做一件事,做得好"(转述)的座右铭,而且它似乎在DI的背景下特别好.
我现在想知道的是,我是否应该将当前单个大型装配拆分为具有不相交特征集的多个较小装配.这些较小的程序集中的一些将具有相互依赖性,但远非所有这些程序集,因为代码的体系结构已经非常松散地耦合.
请注意,这些功能集不是微不足道的,也不是很小......它包含客户端/服务器通信,序列化,自定义集合类型,文件IO抽象,常用例程库,线程库,标准日志记录等.
我看到前一个问题:什么是更好的,许多小型装配,或一个大装配？有点解决这个问题,但是看起来更精细的粒度,这让我想知道那里的答案是否仍适用于这种情况？
此外,在接近这个主题的各种问题中,一个常见的答案是,"太多"集会导致了未指明的"痛苦"和"问题".我真的想要具体了解这种方法可能存在的缺点.
我同意在仅需要1个之前添加8个组件是"有点痛苦",但是必须为每个应用程序包含一个大的单片库也不是完全理想的...加上8个组件只是你做的事情曾经,所以我对这个论点很少有同情心(即使我最初可能会和其他人一起抱怨).
附录:
到目前为止,我已经看到没有针对小型装配的任何理由,所以我想我现在将继续进行,好像这是一个非问题.如果有人能够用可验证的事实来考虑好的可靠理由来支持它们,我仍然会非常有兴趣了解它们.(我会尽快增加赏金以提高知名度)
编辑:将性能分析和结果移到单独的答案中(见下文).