问题描述

如果 asp.net 中的域对象实现 INotifyPropertyChanged 并在属性设置器上触发 PropertyChanged 事件会发生什么?

我有一个用于 Silverlight 和 WebForms 系统的公共域层.为了让 Silverlight 获得所有绑定魔法，域现在会进行属性通知.

我的网络表单系统似乎没有受到影响(一切仍然有效)，但我担心幕后发生了一些我不了解的事情.

我可以创建一个 Silverlight 特定的域层来扩展原始域对象，并覆盖属性以执行通知，但这是必要的吗?即我是否无缘无故地添加了一层额外的代码.

用 ComponentModel 的东西污染我的域确实感觉很丑陋.

可能不会发生任何错误，但这不是最好的方法..

我可以创建一个 Silverlight 特定的域层来扩展原始域对象，并覆盖属性以执行通知，但这是必要的吗?即我是否无缘无故地添加了一层额外的代码.

首先要指出的是，您在 Silverlight 中的 UI 不应绑定到域对象.实际上，您的视图绑定到一个 ViewModel，而这个 viewmodel 应该包含模型.

UI 模型 != 领域模型

用 ComponentModel 的东西污染我的域确实感觉很丑陋.

如果您在域模型中添加表示逻辑，您的业务逻辑层可能会变得一团糟，并且您会失去抽象，因为它与表示层耦合.想象一下，在 2 年后，您转向另一个需要模型中特殊逻辑的 Web 框架，您会在业务对象中添加更多逻辑吗?

在我看来领域模型应该与其他层隔离，并且不应该依赖于某种技术(在这种情况下，是 Silverlight)

我将添加一个新层，将您的域对象转换为 Silverlight 模型.这可能看起来是一种开销，但这样您的系统就会干净且具有清晰的隔离层.

有一些工具可以帮助您轻松完成此映射，例如 AutoMapper

What happens if a domain object in asp.net implements INotifyPropertyChanged and fires off the PropertyChanged event on the property setters?

I have a common domain layer for both a silverlight a WebForms system. For silverlight to get all the binding magic, the domain now does property notifications.

My webforms system doesn't seem to be affected (everything still works) but I am worried that something is happening behind the scenes that I don't understand.

I could make a silverlight specific domain layer that extends the original domain objects, and overrides the properties to do notifications, but is this necessary? i.e. am I adding an extra layer of code for no reason.

Polluting my domain with ComponentModel stuff does feel ugly.

Nothing wrong will probably happen, but it is not the best approach..

I could make a silverlight specific domain layer that extends the original domain objects, and overrides the properties to do notifications, but is this necessary? i.e. am I adding an extra layer of code for no reason.

First thing to point out is that your UI in Silverlight should not be bound to Domain Objects. In fact, your views are bound to a ViewModel, and this viewmodel should contain Models.

UI Model != Domain Model

Polluting my domain with ComponentModel stuff does feel ugly.

If you add presentation logic in your Domain Models, your business logic layer can become a mess and you lose abstraction since it's coupled to the presentation layer. Just imagine that in 2 years you move to another web framework that needs special logic in the models, will you add more logic in the business objects?

In my opinion Domain Models should be isolated from other layers and should not be dependant on a technology (in this case, to Silverlight)

I would add a new layer that would transform your domain objects to Silverlight Models. This might look as an overhead, but this way your system will be clean and with clear isolated layers.

There are tools that can help you to do this mappings without much effort, for example AutoMapper

这篇关于域对象上的 Asp.net INotifyPropertyChanged的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！