小编L-F*_*our的帖子

我正在开发一个WPF Prism应用程序,一切正常.我的视图模型都有接口,由MEF注入.

但是,我并不真正了解视图模型的接口的好处.毕竟,视图与其视图模型相关联,因此我认为永远不会有其他实现.

实际上,我也有我的观点的接口.看来这也有点矫枉过正？

所以我的问题是:我不能只删除所有视图和查看模型接口并直接注入视图和查看模型吗？有没有理由保留视图和视图模型的接口？

Thx,L

我正在建立一个应用洋葱架构和 DDD 模式的解决方案。

DDD 原则之一鼓励域实体仅具有私有 setter 和私有默认构造函数，以确保您无法创建处于无效状态的域实体。

存储库包含域实体上的数据操作，这些实体从数据库映射到数据库。我一直在尝试以下两种方法：

1. 纯粹的领域实体：没有默认构造函数，没有公共设置器；验证在构造函数中完成；这确保您无法创建处于无效状态的域实体。副作用是在读取操作中更难在存储库中对它们进行非物质化；因为您需要反射才能创建实例和映射属性；以及在需要映射到实际域实体的 Dapper 请求中使用动态。如果我将其直接映射到域实体而不使用动态，Dapper 会抛出一个异常，即没有公共构造函数。

2. 以非纯粹的方式实现域实体：允许使用默认构造函数，并且所有 setter 都是公共的；因此您可以创建在给定时间点无效的实体。在这种情况下，您需要手动调用 Validate() 方法，以确保它们有效，然后再继续。这使得存储库中的去物质化变得更加容易，因为您不需要反射或动态来将数据库映射到模型。

然而，这两种方法都有效，使用选项 2 存储库变得更加简单，因为它们包含的自定义映射代码要少得多，而且如果没有反射，显然性能也会更高。当然，DDD 并不是以纯粹的方式应用的。

在决定我将在项目中使用什么之前，有一个问题：是否有任何其他微 ORM 框架可以处理私有构造函数和设置器，以便支持将数据库映射到那些“纯”域实体，而无需额外的操作自定义映射逻辑？（没有 EF 也没有 NHibernate，我想要一些轻量级的东西）。

或者其他技术解决方案来保持“纯”模型实体方法与简单的存储库映射相结合？

编辑：我实施的解决方案如下。

首先，领域实体中的构造函数和设置器都是“内部的”，这意味着它们不能由领域模型的使用者设置。但是，我使用“InternalsVisibleTo”来允许数据访问层直接访问它们，因此这意味着使用 Dapper 从数据库中进行非物质化非常容易（不需要中间模型）。从应用程序层，我只能使用域方法来更改域实体，而不能直接更改属性。

其次，为了从应用程序层构建新的域实体，我添加了流畅的构建器来帮助构建域实体，因此我现在可以像这样构建它们：

 User user = new UserBuilder()
        .WithSubjectId("045454857451245")
        .WithDisplayName("Bobby Vinton")
        .WithLinkedAccount("Facebook", la => la.WithProviderSubjectId("1548787788877").WithEmailAddress("bobby1@gmail.com"))
        .WithLinkedAccount("Microsoft", la => la.WithProviderSubjectId("54546545646").WithEmailAddress("bobby2@gmail.com"))

当构建器“构建”实体时，验证也会完成，因此您永远无法创建处于无效状态的实体。

由于上一篇文章(架构:简单的CQS),我一直在思考如何构建一个足够灵活的简单系统,以便以后扩展.

换句话说:我现在不认为需要一个完整的CQRS,但是如果需要的话,我希望以后能够很容易地发展它.

所以我在考虑将命令与查询分开,但两者都基于相同的数据库.

查询部分很简单:基于视图的WCF数据服务,可以轻松查询数据.没什么特别的.

命令部分更难,这里有一个想法:命令当然是以异步方式执行的,因此它们不会返回结果.但是,我的ASP.NET MVC站点的控制器通常需要来自命令的反馈(例如,如果成员的注册成功与否).因此,如果控制器发送命令,它还会生成与命令属性一起传递的事务ID(guid).命令服务接收此命令,将其放入数据库中具有状态'processing'的事务表中,并执行(使用DDD原则).执行后,事务表将更新,以便状态变为"已完成"或"失败",以及其他更详细的信息,如生成的主键.

同时,该站点使用QueryService来轮询此事务的状态,直到它收到"已完成"或"失败",然后它可以根据此结果继续工作.如果轮询事务表并且结果为"已完成"或"失败",则删除该条目.

副作用是我不需要guid作为我的实体的键,这对性能和大小来说是一件好事.

在大多数情况下,可能不需要这种轮询机制,但如果需要则可以.接口的设计考虑了CQS,因此对未来开放.

你认为这种方法有什么缺陷吗？其他想法或建议？

谢谢!

路德

我有URL的样子:

• / nl/blog(显示博客项目概述)
• / nl/blog/loont-lekker-koken-en-wordt-eerlijkheid-beloond(用urltitle显示博客项目)
• / nl/blog/waarom-liever-diëtist-dan-kok(用urltitle显示博客项目)

我为其定义了路线:

• 答:路线"nl/blog/{articlepage}"与约束articlepage = @"\ d"
• B:路线"nl/blog"
• C:使用约束commentpage = @"\ d"路由"nl/blog/{urltitle}/{commentpage}"
• D:路线"nl/blog/{urltitle}"

问题1:这样可以正常工作,但也许有更好的解决方案,路线更少？

问题2:添加一篇新文章,我在BlogController中有一个动作方法AddArticle.当然,使用上面定义的路由,URL"/ nl/blog/addarticle"将映射到路径D,其中addarticle将是当然不正确的urltitle.因此我添加了以下路线:

• E:路线"nl/blog/_ {action}"

所以现在url"/ nl/blog/_addarticle"映射到此路由,并执行正确的操作方法.但我想知道是否有更好的方法来处理这个问题？

感谢您的建议.

在我的数据库中,我有一个表类别,列ID,CategoryName,ParentCategoryId,其中ParentCategoryId对Category.Id有约束.

我首先使用实体​​框架代码,实体看起来像:

public class Category
{
   public long Id { get; private set; }
   public string CategoryName { get; private set; }
   public long? ParentCategoryId { get; private set; }
   public Category ParentCategory { get; private set; }       
   public virtual ICollection<Category> SubCategories { get; private set; }
}

如果我尝试对此运行查询,我会得到异常:

 The relationship 'ComplaintModel.FK_Complaint_Category' was not loaded because the type 'ComplaintModel.Category' is not available.\r\nThe following information may be useful in resolving the previous error:\r\nThe required property 'Category1' does not exist on the …

当前情况:一个ASP.NET MVC网站,其中包含许多控制器和操作方法,以及允许添加配方的视图.

现在,我必须创建一个WPF应用程序,作为添加配方的UI(与网站相同).

我的问题是:我可以使用ASP.NET MVC站点来公开WPF应用程序使用的服务操作(以及如何完成)？或者我应该为此更好地创建专用的WCF服务,并让WPF和ASP.NET MVC站点使用这些服务？

谢谢,路德维希

这是一个小问题,只是为了确保我正确理解Unity.

我在ASP.NET MVC应用程序中使用Unity,我已经注册了如下类型:

 container.RegisterType<IPizzaService, PizzaService>(); 

我在控制器中使用它,如:

public class PizzaController : Controller
{
    private IPizzaService _pizzaService;

    public PizzaController(IPizzaService pizzaService)
    {
        _pizzaService = pizzaService;
    }

    [HttpGet]
    public ActionResult Index()
    {
        var pizzasModel = _pizzaService.FindAllPizzas();
        ...        
    }        
}

每次页面请求完成时,IPizzaService都会注入并使用新的实例.所以一切正常.

我的问题:我必须做一些特殊处理这个实例吗？我假设,一旦请求结束,控制器就会被处理掉,而PizzaService实例最终会被垃圾收集.

如果我需要确定性地处理实例,因为它使用实体框架上下文或非托管资源,我必须覆盖控制器的Dispose,并确保我自己调用实例的dispose.

对？如果没有,请解释原因:)

谢谢!

我必须在我的数据库中表示数字,这些数字是食物中的化学物质,如脂肪,能量,镁等.这些值是12345.67格式的小数.

如果我decimal (5,2)在SQL Server中用作数据类型,它将映射到DecimalEntity Framework中的类型.如果我在SQL Server中使用float作为数据类型,它将映射到DoubleEntity Framework中.

我不确定SQL Server中最好的数据类型是什么,或者它真的不重要吗？

编辑 - 在我的情况下应该是decimal(7,2),正如一些评论中提到的那样!

谢谢.

我有一个使用Devart和Entity Framework访问的Oracle数据库.

有一个叫做IMPORTJOBS列的表STATUS.

我还有多个进程同时运行.他们每个人都读取IMPORTJOBS有状态的第一行'REGISTERED',将其置于状态'EXECUTING',如果完成则将其置于状态'EXECUTED'.

现在因为这些进程并行运行,我相信可能会发生以下情况:

• 进程A读取具有状态的第10行REGISTERED,
• 进程B还读取仍具有状态的第10行REGISTERED,
• 进程A将第10行更新为状态EXECUTING.

进程B不应该读取第10行,因为进程A已经读取了它并且将更新其状态.

我该怎么解决这个问题？在事务中放入读取和更新？或者我应该使用一些版本控制方法或其他什么？

谢谢!

编辑:感谢接受的答案我得到了它的工作并在此处记录:http://ludwigstuyck.wordpress.com/2013/02/28/concurrent-reading-and-writing-in-an-oracle-database.

我正在研究使用CQRS和DDD原则的分布式系统.基于此,我决定我的实体的主键应该是guids,它是由我的域(而不是数据库)生成的.

我一直在阅读guids作为主键.但是,如果应用于Azure SQL数据库,似乎某些最佳实践不再有效.

1. 如果使用内部SQL服务器机器,顺序guid很好 - 生成的顺序guid将始终是唯一的.但是,在Azure上,情况不再如此.正如在这个帖子中讨论的那样,它甚至不再受支持了; 并且生成它们也是一个坏主意,因为它成为单点故障,并且不再保证服务器之间的唯一性.我猜连续的guid在Azure上没有意义,所以我应该坚持使用常规guid.它是否正确？

2. Guid类型的列是群集的不良候选者.但是这篇文章指出Azure上不是这种情况,而这一点恰恰相反!我应该相信哪一个？我应该只使我的主键成为一个guid并将其保持群集(因为它是主键的默认值); 或者我不应该将其聚类并选择另一列进行聚类？

感谢您的任何见解!