Liviu, We would be glad to accept all the help that you can provide with
writing documentation.
On Wed, Oct 8, 2008 at 8:57 AM, Liviu U <[EMAIL PROTECTED]> wrote:
>
> Regarding : code it yourself advice, this is the biggest pain in the
> with open source projects that do not have the guts to
There is another way to go, when talking about Persistence Ignorance.
I define all my model entities as interfaces in a separate assembly.
I have a "code generator " specific for each storage that takes care
of all the plumbing for me:
1) generates the classes as the storage wants them : NH
There is another way to go, when talking about Persistence Ignorance.
I define all my model entities as interfaces in a separate assembly.
I have a "code generator " that takes care of all the plumbing for me:
1) generates the classes as the storage wants them : NH virtual
methods, primary ke
inline, having played with the POCO adapter for EF, my 2 cents would be do
not use it, and not let any of your good friends do so. Seriously, PI is not
that important to create 3 levels of mapping just to achieve it. (even the
built in 2 makes me choke, but that's even another inline discussion)
O
If EF is the future, then I don't want to see tomorrow.
On Tue, Oct 7, 2008 at 5:50 PM, Fabio Maulo <[EMAIL PROTECTED]> wrote:
> 2008/10/7 MAMMON <[EMAIL PROTECTED]>
>>
>> With a lot of Entity Framework buzz being generated recently, due to
>> it's v1 release with VS2008 SP1, the term Persistence
I didn't compare NH with EF. I simply mentioned that due to recent EF
buzz, and EF's LACK of Persistence Ignorance, the topic of PI had been
on my mind. The only phrase that could have been interpreted as a
comparison between the two was when I praised NHibernate, mentioning
how nice it was that
My point of view on that is quite simple, I am working on open source
projects for many reasons.Part is personal pleasure, part is to have good
tools at my disposal.
My interest in adding features that I don't need and don't care about is
low. Developing software takes time, and unless I, personall
2008/10/7 MAMMON <[EMAIL PROTECTED]>
> With a lot of Entity Framework buzz being generated recently, due to
> it's v1 release with VS2008 SP1, the term Persistence Ignorance has
> been climbing the Google ranks ladder. Indeed, a Google search of the
> term shows that of the top 5 results, 3 are a
On Wed, Oct 8, 2008 at 12:24 AM, Fabio Maulo <[EMAIL PROTECTED]> wrote:
> If you want I have the only one unsolvable intrusion
> With NH you must have an ID as your POID even if your Entity don't need it
>
Can't you just not specify the ID in the mapping? That will make NH manage
it intenrally.
If you want I have the only one unsolvable intrusion
With NH you must have an ID as your POID even if your Entity don't need it
In the past I found 3 intrusions of NH in my entities but when I saw the NH
core code I understand that the other 2 was only because I'm asking to NH to
solve some other
2008/10/7 MAMMON <[EMAIL PROTECTED]>
> but it DOES:
> + Force me to make all of my methods and properties virtual, for the
> use of proxies
It is not NH. It is a requirement of Castle.DynamicProxy and in general a
requirement of any kind of DynProxy.
Unluckily .NET don't give us a buildin system
I did? I don't recall that.
Ctor mapping isn't really different than the other forms of mapping that
Nhibernate has.
It is different because you need to gather the data up front and then create
the instance, but it is possible.
Start from Loader.GetRow and move from there.
It is not trivial, but i
Funny in past conversations you determined that supporting constructor
mapping would require so much rewriting/rearchitecture that it wasn't
viable to look at ...
Now you ask me for a patch.
hmm.
Cheers,
Greg
On Tue, Oct 7, 2008 at 1:18 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote:
> Patch it
MAMMON <[EMAIL PROTECTED]> writes:
> So does NH really achieve Persistence Ignorance?
IMNSHO it's a dumb idea to try to make your business layer completly
persistence ingnorant (in the way you suggest), because there is some
persistence in the background and you are developing a complex
system. H
The EmptyInterceptor is exactly what I needed. This is excellent, now
I can get all that auditing in there that I want. Thanks!
On Oct 7, 1:27 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> You can selectively intercept by using EmptyInterceptor as a base class,
> which will also deal with th
Patch it to make it work better for your scenarios. That tends to be easier
than just living with awkwardnss.
On Tue, Oct 7, 2008 at 10:13 PM, Greg Young <[EMAIL PROTECTED]> wrote:
>
> Let me clarify, it supports it. It's just very painful in implementation...
> On 10/7/08, Ayende Rahien <[EMAIL
You can selectively intercept by using EmptyInterceptor as a base class,
which will also deal with the default behavior appropriately.
That was not a defensive answer, by the way, that was an expression of
intent. If you don't like it, fix it.
The source is there, and the architecture supports it.
"Write your own" is never a very good answer. I know I was bringing
up a touchy subject, but was hoping to avoid defensive answers. I
like the performance the proxies give me, and I like the support for
lazy loading, but that doesn't mean there aren't restrictions and
shortcomings.
I actually d
Let me clarify, it supports it. It's just very painful in implementation...
On 10/7/08, Ayende Rahien <[EMAIL PROTECTED]> wrote:
> Greg,
> IInterceptor.Instansiate ?
>
> On Tue, Oct 7, 2008 at 10:06 PM, Greg Young <[EMAIL PROTECTED]> wrote:
>
>>
>> PI has always been defined as the domain not havi
Greg,
IInterceptor.Instansiate ?
On Tue, Oct 7, 2008 at 10:06 PM, Greg Young <[EMAIL PROTECTED]> wrote:
>
> PI has always been defined as the domain not having any changes in
> specific for it persistence mechanism.
>
> I believe we can give credit to Jimmy Nilsson for creating in the term
> in A
PI has always been defined as the domain not having any changes in
specific for it persistence mechanism.
I believe we can give credit to Jimmy Nilsson for creating in the term
in ADDDP (Applying Domain Driven Design and Patterns).
You could use nhibernate in a more classic repository implemen
There is nothing in NHibernate that demands that you would use the
DynamicProxy support.
NHibernate's proxies are pluggable, just build your own if it bothers you.
On Tue, Oct 7, 2008 at 9:55 PM, MAMMON <[EMAIL PROTECTED]> wrote:
>
> Lately I've been thinking about Persistence Ignorance. In the
22 matches
Mail list logo
