小编Rob*_*zak的帖子

在Silverlight 3.0中使用.NET RIA Services和MVVM时,RIA Services的Metadata类型和MVVM模式的ViewModel之间存在差异吗？这些是相同的还是应该分开？

元数据类型是部分Entity类的密封内部类.似乎没有适当的分离,但元数据类型也可以使用Validation的属性进行修饰,使其看起来像ViewModel.

我一直在四处寻找,但我没有看到任何有关这方面的细节.

我在设计Silverlight 3 LOB应用程序三周后,我决定使用Entity Framework,RIA Services和MVVM模式.

现在我正在调查所有胶水.我正在检查行为,ICommand,依赖属性,IoC等.

在撰写本文时,Silverlight有许多框架.

Silverlight.FX
Silverstone
CSLA用于Silverlight
Prism
Caliburn

这些必要吗？
您是否有使用这些框架的经验？
这些框架是否仍适用于Silverlight 3？
使用这些框架的优点和缺点是什么.

说实话,我对CSLA并不感兴趣,因为我们今天没有使用它,但我把它包括在内是为了完整性.

我可以看到两种方法将ViewModel连接到View.一个在XAML中,另一个在后面的代码中通过依赖注入.

哪种方法更优选？我更喜欢xaml方法,因为我根本不需要代码中的任何代码,但是其中一个代码有什么问题吗？

<navigation:Page x:Class="MyNamespace.MyViewModel" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   xmlns:ViewModel="clr-namespace:MyNameSpace.MyViewModel"
   xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
   Title="ViewModel Page" >

    <navigation:Page.Resources>
        <ViewModel:MyViewModel x:Key="ViewModel"></ViewModel:MyViewModel>
    </navigation:Page.Resources>

    <Grid x:Name="LayoutRoot" Background="White" 
          DataContext="{StaticResource ViewModel}">

    </Grid>
</navigation:Page>

要么

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Windows.Navigation;

namespace MyNamespace
{
    public partial class MyView : Page
    {
        public MyView()
        {
            InitializeComponent(MyViewModel viewModel);

            this.DataContext = viewModel;
        }
    }
}

我基于过去4或5年使用C#属性的许多设计和框架.

但最近我看到许多人开始不鼓励他们使用或改变他们的框架以减少他们的需要或使用.

我发现它们是天赐之物,但现在我开始怀疑自己错过了什么.

澄清:使用约定优于配置正成为遵循ORM领域的主要原则.此区域是否可以使用配置文件(XML)映射字段,使用属性或具有直接映射到数据库表中字段的通用命名约定.我没有引用任何引用,但我已经阅读了一些反对添加另一个属性的反对意见.

但我觉得在我刚刚列出的三个选项中,属性仍然是最有意义的.Config文件难以维护,常见的命名约定将您与数据库字段的实现联系起来.属性被准确放置在需要它们的位置,并且实现可以在不断开其使用位置的情况下进行更改.

我没有看到隔离存储的很多价值,除了可能暂时缓存一些图像或本地代码.因为你只获得1MB,即便如此,我也看不到它的重要价值.在隔离存储中保存设置没有多大意义,因为用户可以从另一台机器上的另一个浏览器访问您的silverlight应用程序.

Plus Settings更有意义地存储在服务器上.

你可能错过了什么使用IsolatedStorage？