关于在使用基于SQL的数据库时是否尊重OOP/MVC数据模型设计的讨论

我想听听人们对数据建模与SQL（OOP与Select语句）的概念在以下方面的看法： 在研究MVC和OOP概念时，很容易看到以下内容的自然形式：

<php? | <% | <#

Class Country{
     _name:String;
     _language:String;      
}

Class Estate{
     _name:String;
     _country:Country;
}

?> | % | #>

很抱歉混合了语言语法，我不想太依附于语言，只是概念

现在让我来总结一下我的想法：根据理论，这是正确的概念。就我个人而言，我认为不同意这一点是不对的，因为这是事情的逻辑。但在实践中，现实世界永远不会如你所愿闪耀，我从中看到：

如果我有10个属性，我将在硬盘级别上执行11条SQL语句（根据操作系统的理论，这是所有存储内存中最慢的一条）。

如果我有100个Estate，我将执行101条SQL语句。

如果我有n个Estate，我将执行n+1个SQL语句。

我的最后一点：我认为，如果要对可能有数千条记录的数据实体进行建模，这可能会是一个真正的难题。基于这种思路，我在使用Flex+PHP时拒绝使用这种设计逻辑。但现在我正在尝试构建一个应用程序，它将Flex和ExtJS作为查看器，PHP作为服务器端，我只想确保我不会因为无关紧要的原因而选择最困难的路径。不尊重这种MVC/OOP逻辑更安全吗？我是在夸张吗？您如何看待面向对象编程中的SQL与数据模型

---

谢谢。

你可以两全其美。您不需要以存储在内存中的方式存储对象，即使这样，您也可以对其他对象建模，以便能够以高效的方式保存它们： 鉴于：

您可以创建：

Class EstateWithCountryInformation{
     _estateName:String;
     _countryName:String;
     _language:String;      
     getEstate();
     getCountry();
}

并且只有Country和EstateWithCountryInformation表。这样，您就可以在一个查询中获得所需的内容。如果您需要只查询房地产信息，也可以从EstateWithCountryInformation表中获取，或者您甚至可以创建一个数据库视图来模拟该表

---

我不知道您使用什么来访问数据库，但我知道一些带有高级映射选项的ORM，它允许您使用最初定义的类，并自动映射到EstateWithCountryInformation（如表），当您查询一个Estate时，然后调用new CountryDAO（）。getCountryById（）它们将信息缓存在内存中，因此不会进行任何额外的数据库访问。

我建议不要使用直接映射到数据库表的DAO实现。相反，您应该研究模式

其基本思想是，在模型层中，将业务逻辑分离到数据映射器中，将数据库交互分离到数据映射器中。这样，当您需要获取项目集合（如100个地产的详细信息）时，映射器只执行1或2次查询，并将数据转储到域对象中，域对象处理集合

每个映射器可以轻松地处理一个DB表中的多个映射。mapper的目标是获取域对象并将其与存储接口。没有法律规定域对象只能使用一个表

无论如何，MVC设计模式与存储信息的位置无关。它只处理用户界面和域业务逻辑的分离。SQL交互（如果您甚至使用SQL数据库而不是其他数据源）深入到模型层中

我强烈建议你阅读这篇文章：由马丁·福勒撰写

---

另外，如果您主要使用PHP，您可能会发现它很有用。

谢谢，这很有帮助。现在我想我知道为什么我应该考虑学习如何使用Orm Orm。

Class Country{
     _name:String;
     _language:String;      
}
Class Estate{
     _name:String;
     _country:Country;
}

Class EstateWithCountryInformation{
     _estateName:String;
     _countryName:String;
     _language:String;      
     getEstate();
     getCountry();
}