Just Imagine if someday, you have to reference your domain on another
software that has nothing to do with nhibernate whatsoever? Would you like
to have to install NHibernate just to access a "DoCalculationXYZ(int val,
int val2, int val3, AnyEnum type)" method?
I might be wrong but that's what I thought when I decided to isolate my
domain on an exclusive assembly.
On Wednesday, February 19, 2014 9:36:26 AM UTC-3, PeteA wrote:
>
> Hi folks,
>
>
>
> We're currently setting up a 'template' solution for future development,
> and I'm torn as to whether or not to have the bycode mappings in the same
> assembly as the domain entities or if they should be split out. At the
> moment, I'm embedding the mapping classes inside each entity, e.g.
>
>
>
> class User : EntityBase {
>
> string UserName { get; set; }
>
>
>
> public class Mapping : Mapper<User> {
>
> }
>
> }
>
>
>
> On the one hand, I like the way that this (1) keeps the entity + mapping
> next to each other, (2) keeps the mapping 'hidden away' so it doesn't get
> picked up by intellisense etc. and (3) doesn't require an assembly
> containing nothing but mappings (a bit like a one-to-one relationship with
> assemblies!); on the other hand, I intensely dislike having a reference
> from the domain assembly to NHibernate (although we're a web-based
> solution, so the external API is REST/JSON-based anyway and this doesn't
> impact consumers).
>
>
>
> What are other peoples thoughts on this please? Has anyone else got an
> elegant solution to this?
>
>
>
> Thanks,
>
> /Pete
>
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/groups/opt_out.
