Is it common to put fluent mapping in the same project as the entities?

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 appreciate开发者_开发百科d.

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.

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