将流畅映射与实体放在同一项目中是否常见？
在过去的两年里，我的同行、博客和书籍教导我，一个像样的解决方案的基本项目结构应该分为 Presentation、Data、>实体作为单独的项目。 （更多取决于某些事情需要多少层。例如，在某些情况下可能有一个过渡层）
但是当我使用 Fluent nHibernate 时，我发现自己不断在两个之间重建相同的目录结构不同的 Visual Studio 项目 - 目的是什么？有人告诉我，这是由于关注点分离的想法，因此可以交换层......但说真的，人们实际上经常交换整个数据访问层吗？
将您的 Fluent 映射捆绑到它们映射到的实体所在的同一个项目中，这是标准的还是......在实践中不被嘲笑？我不应该这样做有什么逻辑原因吗？我在各方面都是新手，非常感谢任何意见。
For the last two years I've been taught by my peers and blogs and books that basic project structure for a decent solution should be separated out into Presentation, Data, Entities as individual projects. (More depending on how many layers you need for certain things. For instance, there may be a Transitional layer in some cases)
But as I use Fluent nHibernate I find myself constantly rebuilding the same directory structure between two different Visual Studio projects - and for what purpose? I'm told this is due to the idea of separation of concerns and so that the layers can be swapped... but seriously, do people actually swap out entire data access layers frequently?
Is it standard or even ... non-laughed at practice to just bundle your Fluent Mappings into the same Project where the Entities they are mapped to reside? Is there any logical reason why I shouldn't do this? I am a novice in every regard and any opinion is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一点是您并不总是希望或能够公开数据访问（映射）。特别是，通常只有一个组件使用数据访问层，而许多其他部分仅使用数据类 API，从不了解数据访问。在我当前的项目中，客户端应用程序运行在无法处理 NHibernate 引用的环境中，这使得无法进行数据访问。但客户端确实使用数据类。在另一个项目中，我的（自动生成的）数据类在多种编程语言和平台上使用。始终将它们放在单独的模块/程序集/项目/其他内容中，无论使用什么平台，都拥有一致的 API，这样会更加一致。只有服务器正在使用数据访问。
其次，最好将尽可能多的独立事物分开，由于很多原因我都懒得提及。
另外，根据我的经验，交换数据访问层并不罕见。
顺便说一句，为什么不断将实体与数据类分离对您来说如此麻烦？是的，使用当今仍不完善的编程工具，您会发现自己一次又一次地重复相同的实践（希望不是重复代码），但这是有充分理由的。
One point is that you don't always want to, or can, expose the data access (mappings). In particular, there is usually only one component that uses the data access layer, and many other parts that only use the data classes API and never know about data access. In my current project the client application is running in an environment that can't handle references to NHibernate, which makes it impossible to have data access stuff. But the client does use the data classes. In another project, my (autogenerated) data classes were being used across several programming languages and platforms. It was much more consistent to always have them in a separate module/assembly/project/whatever, to have a consistent API regardless of the platform being used. Only the server was using the data access.
Secondly, it's always better to separate as much as possible things that are independent, for many reasons I'm too lazy to mention.
Also, from my experience it's not uncommon to swap data access layers.
By the way, why is it such a nuisance for you to keep separating the entities from the data classes? Yes, with today's still imperfect programming tools you'll find yourself repeating again and again the same practices (hopefully not repeating code), but for a good reason.
虽然人们并不经常更换数据访问层，但这并不是让这样做变得困难的好理由。如果明年出现另一个更好的 ORM，您可以简单地将 Fluent NHibernate 映射替换为数据访问项目中新 ORM 的映射，而无需对客户端逻辑进行任何更改。事实上，如果您愿意，您甚至可以提供在运行时使用其中任何一个的选项。
将数据映射移到域对象之外的另一个原因是促进对象的重用。假设您决定在另一个不需要将域对象存储在数据库中的项目（如客户端应用程序）中重用域对象（您现在使用 Fluent NHibernate 映射的对象）。您不希望您的客户端应用程序具有依赖性
While it isn't that often that people swap out their data access layers, this isn't a good reason to make it hard to do so. If another better ORM comes around next year, you can simply replace your Fluent NHibernate mappings with mappings for the new ORM in your Data Access project without making any changes to the client logic. In fact, you could even provide the option of using either one at runtime if you wanted to.
Another reason to move the data mapping outside of the domain objects is to promote re-use of the objects. Lets say you decide to re-use your domain objects (the ones you're mapping with Fluent NHibernate now) in another project that doesn't need to store them in a database, like a client application. You wouldn't want your client application to have a dependency