模型-视图-呈现器和传输大型对象

发布于 2024-09-13 14:21:03 字数 774 浏览 6 评论 0原文

我传统上实现了一个模型-视图-呈现器 [被动视图],如下所示:

interface IView
{
string Title {set;}
}

class frmTextBox : Form, IView
{
...
public string Title
{
set { this.txtTitle.Text = value; }
}
...
}


class frmLabel : Form, IView
{
...
public string Title
{
set { this.lblTitle.Text = value; }
}
...
}

class Presenter
{
private IView view;
...
public void UpdateTitle
{
this.view.Title = "A Good Title";
}
...
}

并且我传统上仅在 IView 接口中使用原始类型(intstring, bool),因为我一直明白你只需要在视图中使用原始类型。在存储库(例如 NHibernate)中,如果我想在 DataGridView 中显示项目列表,我必须传递一个通用集合(IList;) 从模型到演示者。这是否违反了视图背后仅由原始类型组成的规则,或者这在架构上可以吗?

即使我有一个数据传输对象(DTO),它也更像是一个监督控制器,而不是我试图实现的被动视图样式。

想法??

I have traditionally implemented a Model-View-Presenter [Passive View] like so:

interface IView
{
string Title {set;}
}

class frmTextBox : Form, IView
{
...
public string Title
{
set { this.txtTitle.Text = value; }
}
...
}


class frmLabel : Form, IView
{
...
public string Title
{
set { this.lblTitle.Text = value; }
}
...
}

class Presenter
{
private IView view;
...
public void UpdateTitle
{
this.view.Title = "A Good Title";
}
...
}

and I have traditionally only used primitive types in the IView interface (int, string, bool) because I have always understood that you need to use primitive types only in the View. In a Repository (such as NHibernate), if I want to display a list of items in a DataGridView, I have to pass a generic collection (IList<T>) from the Model to the Presenter. Does that violate the rule behind views as consisting only of primitive types or would this architecturally be OK?

Even if I had a Data Transfer Object (DTO), that would be more of a supervising controller rather than passive view style I am trying to implement.

Thoughts??

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

遇到 2024-09-20 14:21:03

模式的存在可以帮助您根据他人的经验设计解决方案。

它们只不过是形式化的模板。

使用任何可以提高工作效率的结构,即使它并不完全符合任意定义。

Patterns exist to help you design your solution based on others' experiences.

They are nothing more than formalized templates.

Use whatever structure makes you more productive, even if it doesn't fit an arbitrary definition perfectly.

浅唱々樱花落 2024-09-20 14:21:03

哇,也许我错过了很多。我从未见过视图仅限于显示原始类型。

我很想知道为什么使用此限制以及它的好处是什么?这并不是说“在我看来,这是完全错误的”,但我很好奇它的好处。我相信,计算机现在已经足够强大,除非您以特定的性能规范为目标,否则开发人员努力适应某些准则的成本将是对资源的昂贵使用。

这本身并不是任何认可。但我见过的所有 MVC 文章都愉快地将视图和控制器之间的类结合起来。由于 MVP 只是 MVC 的一种不同形式,我想说如果这不是 MVC 的问题,那么 MVP 也应该有问题吗?

Wow maybe I've been missing out on a lot. I've never seen views as being limited to only displaying primitive types.

I'd be interested to know why this restriction is used and what the benefit of it is? That's not to say that "IMO it's totally wrong", but I'm curious as to its benefits. My belief is that computers are sufficiently powerful now that unless you are targetting a specific performance specification the cost of a developer hammering away to fit some guideline would be an expensive use of resources.

Not that it's any endorsement per se. but all the MVC articles I've seen have been happily banding around classes between the view and controller. Since MVP is just a different form of MVC I'd say if it's not a problem with MVC should it be with MVP?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文