NHibernate LITE - remove Bytecode, Oracle, Web, Proxy, LazyInitialization, log4net

[Huge]

Greetings,
I was wondering if it would be possible to make available a so-called
"Lite" build of NHibernate. NHibernate seems to have a lot of
features that I do not want or need, and I'm concerned about the >2MB
download size.

Lazy Initialization: this is the one I would most love to get rid of.
Yes I have read hundreds of posts singing the praises of why Lazy
Initialization is so great. Well my particular app cannot benefit
from Lazy Initialization at all. I want to completely disable this
feature. It seems to me that there should be a global place in the
Config where you can disable Lazy Initialization.

FYI the guidance on using a short-lived ISession and the seemingly
forced usage of the Lazy Load feature seems in direct contradiction to
me. On the one hand it is recommended to use a short-lived ISession.
Well if it is short lived and my collections are not loaded as I wish,
then when I do get around to accessing those collections I always get
a nasty LazyInitializationException. Can't I just turn of Lazy
Loading in a global Config setting, pretty please?

When you download NHibernate there are the 2 folders: required_bins
and required_for_lazy_loading which has the Castle and Linfu DLLs.
What if I don't want to use Lazy Loading AT ALL? How can I run
NHibernate without a dependency on these Proxies? This should be an
available option! I'm forced to choose one of the Bytecode providers
or NHibernate won't run.

Sure log4net is great but it doesn't belong in our production app! We
already have a legacy logger that cannot be replaced. So I need an
option to not have a reference to log4net. Why isn't this a compile
switch or something? All this baggage!

I'm writing a Windows WPF desktop app that interfaces with MSSQL
Server. So why do I now have a reference to System.Data.OracleClient
and System.Web after linking to NHibernate? These extra DLLs really
bloat my project and I need a compile option to get rid of the extra
stuff I don't need. My users must download my app and now it grew by
>2MB because of a bunch of stuff I don't need that's tacked onto
NHibernate.

...in short, a LITE build of NHibernate.

I have done a couple things towards making my own compile of
NHibernate without the OracleClient references. I'm just really
baffled that NHibernate is such a widely used ORM but has these extra
dependencies built in and required.

I should be able to use NHibernate in a stripped down form to just
give me the basic ORM functionality I need without all this extra
baggage.

Thank you for listening.
Hugh

[Jason Dentler]

We can't strip out large parts of NH core without introducing breaking changes. Why not explain your use case in some detail?

#1 - You can turn off lazy loading in your mappings and write a tiny, dumbed-down bytecode provider that doesn't do proxies. Solved.

#2 - Session is the unit of work. What is your definition of short lived? An unending war with lazy initialization exceptions is almost always an indication of some deeper architectural issue or a misunderstanding of the feature.

#3 - log4net is 264K. The benefit we get from it GREATLY outweighs any "bloat" from the hard dependency. By the way, there is some discussion of making it pluggable with common logger, but this is yet another DLL.

#4 - I'm not sure where you got your info about OracleClient. I checked with a buddy (Jose Romaniello, my NH+WPF guru) and he says you don't need System.Data.OracleClient.dll to run NH unless you actually use it. 

#5 - No wait. That's all of it. Phew.

Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[Fabio Maulo]

You don't need NHibernate. What you are looking for is Linq2Sql.

--
Fabio Maulo

[Jason Meckley]

@fabio +1

@Huge, what you are asking for is NH without NH. It like asking for a
car, with no wheels and no engine.

On Aug 3, 9:34 pm, Fabio Maulo <fabioma...@gmail.com> wrote:
> You don't need NHibernate. What you are looking for is Linq2Sql.
>
> --
> Fabio Maulo
>

[Frans Bouma]

> I was wondering if it would be possible to make available a so-called
"Lite"
> build of NHibernate. NHibernate seems to have a lot of features that I do
> not want or need, and I'm concerned about the >2MB download size.
>
> Lazy Initialization: this is the one I would most love to get rid of.
> Yes I have read hundreds of posts singing the praises of why Lazy
> Initialization is so great. Well my particular app cannot benefit from
Lazy
> Initialization at all. I want to completely disable this feature. It
seems
> to me that there should be a global place in the Config where you can
> disable Lazy Initialization.

AFAIK, you can switch this off in the mapping files.

> FYI the guidance on using a short-lived ISession and the seemingly forced
> usage of the Lazy Load feature seems in direct contradiction to me. On
the
> one hand it is recommended to use a short-lived ISession.
> Well if it is short lived and my collections are not loaded as I wish,
then
> when I do get around to accessing those collections I always get a nasty
> LazyInitializationException. Can't I just turn of Lazy Loading in a
global
> Config setting, pretty please?

see above

> When you download NHibernate there are the 2 folders: required_bins and
> required_for_lazy_loading which has the Castle and Linfu DLLs.
> What if I don't want to use Lazy Loading AT ALL? How can I run NHibernate
> without a dependency on these Proxies? This should be an available
option!
> I'm forced to choose one of the Bytecode providers or NHibernate won't
run.

Use a commercial grid and you realize that a couple of assemblies
more isn't a problem. any 3rd party tool/framework comes with assemblies,
c'est la vie.

> Sure log4net is great but it doesn't belong in our production app! We
> already have a legacy logger that cannot be replaced. So I need an option
> to not have a reference to log4net. Why isn't this a compile switch or
> something? All this baggage!

Why are you so concerned? Are your users using 14K4 modems?

> I'm writing a Windows WPF desktop app that interfaces with MSSQL Server.
So
> why do I now have a reference to System.Data.OracleClient and System.Web
> after linking to NHibernate? These extra DLLs really bloat my project and
I
> need a compile option to get rid of the extra stuff I don't need. My
users
> must download my app and now it grew by
> >2MB because of a bunch of stuff I don't need that's tacked onto
> NHibernate.

references to .NET framework assemblies don't bloat your project nor
your assembly.

> ...in short, a LITE build of NHibernate.
>
> I have done a couple things towards making my own compile of NHibernate
> without the OracleClient references. I'm just really baffled that
> NHibernate is such a widely used ORM but has these extra dependencies
built
> in and required.
>
> I should be able to use NHibernate in a stripped down form to just give me
> the basic ORM functionality I need without all this extra baggage.

use linq to sql then.

FB

>
> Thank you for listening.
> Hugh
>

[Jason Dentler]

I think this is relevant to the discussion:

http://ayende.com/Blog/archive/2010/08/04/nhibernate-is-lazy-just-live-with-it.aspx

[Huge]

Thanks Jason,

#1 - I don't know how to write a Bytecode provider. I had never heard
of that before a couple weeks ago. To me it is still just something
that gets in the way, some extra thing I have to have in order to use
NHibernate. I know, I'm being naive. So I'll have to devote some
days to doing research on that, now.

#2 - I have objects that last the entire lifetime of the application.
When certain features of the app are accessed, certain subobjects of
those lifetime objects must be loaded at that time. Our application
is for the management and running of a Doctor's office. While we do
have some functionality that fits into the Unit of Work paradigm, we
have quite a bit that does not.

#3 - At my office I am the keeper of the bytes. Nobody else will
watch the size of the download but me. One thing I cannot stop doing
because it is part of my blood, is trying to optimize network
traffic. That means everything from properly compressing JPG/PNG/GIF
images for use on the web, to monitoring the size and number of third
party DLLs that make their way into our customers's downloads. Some
of our customers really are using very old and outdated equipment and
I try always to get the product down to the simplest and smallest
form. It does make a difference for these people.

#4 - I am now using my own build of NHibernate that doesn't have
System.Data.OracleClient or System.Web references. The reason for
this is to be compatible with the so-called .Net 3.5 Framework "Client
Profile" which doesn't include either of those.

Thank you everyone else for your responses as well. I had considered
Linq2SQL previously but since I had such a terrible time with Entity
Framework 4's poor Optimistic Concurrency implementation, I moved away
from Microsoft ORM. Now, considering your responses, I will revisit
Linq2SQL and see if that will satisfy our needs.

Hugh

[Fabio Maulo]

perhaps you have to remove even the reference to log4net

Hugh

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

--
Fabio Maulo

[Jason Meckley]

Huge, the more you explain what you are looking for the less NH fits
your needs. it sounds like you want transaction scripts, not an ORM.
An ORM is more than simply CRUD. It's cache, change tracking,
concurrency, unit of work, etc. transaction scripts are just CRUD
statements. this may better suite your needs.

[Jason Dentler]

You can maybe do some stuff to work around your other issues, but it won't be easy. Even still, you can't remove the Unit of Work concept from NHibernate.

 

IMO, keeping entities around for the lifetime of the app is bad architecture regardless of your ORM choice.

 

Thanks,

Jason

 

[Huge]

Thanks for the feedback but I really do believe that my app is
different! I really do need to keep Entities in memory the whole life
of the app. Here is the justification:

There are numerous places all over the Application surface where it is
required to display a list of Doctors in the Medical Practice.
Sometimes, they appear as columns of a grid (on the Scheduler).
Sometimes, they appear as options in a drop-down box when the user
must associate something with a Provider. Users of the software
schedule Doctor's Appointments all day, with high frequency and
concurrency. It is not even conceivable to go re-select the list of
Doctors every time a user wants to schedule an appointment! It
happens way too frequently!

So, Doctors are loaded into memory for the entire duration of the
application! They are used frequently and for widely varying
purposes. So are Entities that represent all the possible Users of
the software, because they are connected via P2P connection and can
come online and offline intermittently. All the Users are loaded in
memory the whole life of the app! I don't need to re-select them
whenever a user goes online or offline, I am notified instantly on the
P2P network connection. In practice both of these lists are small (<
50 records) for all known users of the software.

I don't appreciate people passing judgement on something they know
nothing about and saying I have bad architecture. I have put a lot of
time into creating an architecture that works uniquely well for our
situation. Just because this app doesn't always fit the usual
scenario of "I have to display an edit form so fire up the Unit of
Work", doesn't mean my situation is invalid!

"An ORM is more than simply CRUD. It's cache, change tracking,
concurrency, unit of work, etc. transaction scripts are just CRUD
statements."

Thank you. I need some of those features though. I don't see why I
have to use LazyLoading in order to get those benefits. Yes, I need
CRUD. But I also need Concurrency checking. And I need caching. I
need UOW when I pop an edit form, but I definitely don't always need
to use UOW, as you can see from what I wrote above. Linq2Sql can't do
all of this, and that's why I'm using NHibernate!

Huge

[Diego Mijelshon]

What you just described is perfectly handled by entity and query caching.

Stop thinking your app is so special and different from anything else. It's not.
 
    Diego

--

[Jason Meckley]

with NH all query (get/load/create..) and command (save, delete,
flush, ...) operations are a unit of work and all units of work
require a transaction. those are the rules of NH.

In regards to architecture: I can see why you would think singletons
are the best (or at least a good) choice for common data access.
Singletons are stateless they work the same no matter what context
they are used in. domain objects have state. keeping stateful objects
in a stateless environment will lead to a complicated mess at best and
a failed system at worst.

That's not to say your idea and strategies won't work, apparently they
currently do according to your statements. But they won't work with
NH. You want NH to work in a way it was never designed and you are
reaching a point where you need to make a choice. Accept the "rules"
of NH and play be them, or don't use NH. You're application won't
succeed or fail because you do or do not use NH. It just doesn't fit
with your architecture and design concepts.

On Aug 4, 6:41 pm, Diego Mijelshon <di...@mijelshon.com.ar> wrote:
> What you just described is perfectly handled by entity and query caching.
> Stop thinking your app is so special and different from anything else. It's
> not.
>
>     Diego
>

> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .

[Huge]

Thanks. I see what you mean about query and command being UOW.

I'm sorry if people think I'm trying to say things bad about
NHibernate, I'm not. I just am new to NH and there's a few things
that I wanted help with. I really do appreciate all the time that
people are taking to help me understand.

I have just one more question about Lazy Loading and Bytecode
providers: I guess what I really want is for the ORM to be neither
"Lazy" nor "Eager". I don't want to disable Lazy loading at the
expense of having everything Eager. What I really need is an Explicit
Loading option. One that means, only load relationships that I
explicitly ask for via an Eager query, or just leave them null. For
my purpose, that would be better than having an uninitialized Lazy
collection that's ready to throw a Lazy Exception, after the original
Session has been closed. Could this be achieved by using my own
custom "Empty" bytecode provider as Jason Dentler originally
suggested?

Hugh

[Fabio Maulo]

For collections you have to implements ICollectionTypeFactory and inject it through NH's configuration or through Bytecode-provider

To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

--
Fabio Maulo

[Vadim Chekan]

On Aug 4, 2:43 pm, Jason Dentler <jasondent...@gmail.com> wrote:
> IMO, keeping entities around for the lifetime of the app is bad architecture
> regardless of your ORM choice.

Love it when you judge design even before you know what are the
requirements ;)

How about all kind of dictionaries: list of countries, time zones of
the worlds, names of world currencies? How frequently do you want to
re-load time zones from DB? At the same time Daylight Time do change
from time to time and you can not hardcode it. For some applications,
let's say desktop it is perfectly valid assumption that time zone does
not change during application life time.

Vadim.

[Vadim Chekan]

I don't understand your argument. Whatever NH is, if I use a feature
from a project, and this project *forces* me to use every feature it
has, it is just wrong.

Vadim.

[Diego Mijelshon]

That's what caching is for.

    Diego

--

[José F. Romaniello]

cache or sometimes this :

http://fabiomaulo.blogspot.com/2009/08/from-db-to-ram-wellknowinstancetype.html

2010/8/5 Vadim Chekan <kot.b...@gmail.com>

[Diego Mijelshon]

I was gonna name that too, but let's assume that the data _is_ mutable, even if that doesn't happen often.
 
    Diego

[Jason Dentler]

Vadim,

Let's review:

User: "I have [x] problem"

Volunteer: "Are you doing [y]?"

User: "Yes. How did you know?"

Volunteer: "We see this all the time. Don't do [y]."

User: "But [y] works."

Volunteer: "No, it doesn't. You just said you had [x] problem."

User: "You're an idiot. [y] is fine. NH sucks."

Random 3rd Party: "Zomg! [volunteer] is judging [user]'s use of [y] without knowing the facts!"

Volunteer: "Fine. I'm an idiot and NH sucks. Go use Linq2Sql and leave me alone."

Like Jason M said, stateful singletons are a recipe for disaster, and any entity associated with a session is stateful. It's a fact of NH that can't be changed.

btw - For the data you describe, use Fabio's WellKnownInstanceType. It's in the link Jose posted. 

Thanks,

Jason

--

[Jason Meckley]

"What I really need is an Explicit Loading option. One that means,
only load relationships that I explicitly ask for via an Eager query,
or just leave them null. "

Have you heard of LLBL Gen Pro (http://www.llblgen.com/
defaultgeneric.aspx). This ORM allows you to decide between either
Lazy Loading (Self Service) or Eager Loaded (Data Adapter) entity
models. This fulfills your previous statement. This decision is made
at design time, not run time. It may be more to your liking. The last
time I used LLBL was v2. At that time it did not use POCO's for the
domain entities not sure if this changed with v3 or not since it now
supports multiple ORMs

On Aug 5, 4:07 pm, Jason Dentler <jasondent...@gmail.com> wrote:
> Vadim,
>
> Let's review:
>
> User: "I have [x] problem"
> Volunteer: "Are you doing [y]?"
> User: "Yes. How did you know?"
> Volunteer: "We see this all the time. Don't do [y]."
> User: "But [y] works."
> Volunteer: "No, it doesn't. You just said you had [x] problem."
> User: "You're an idiot. [y] is fine. NH sucks."
> Random 3rd Party: "Zomg! [volunteer] is judging [user]'s use of [y] without
> knowing the facts!"
> Volunteer: "Fine. I'm an idiot and NH sucks. Go use Linq2Sql and leave me
> alone."
>
> Like Jason M said, stateful singletons are a recipe for disaster, and any
> entity associated with a session is stateful. It's a fact of NH that can't
> be changed.
>
> btw - For the data you describe, use Fabio's WellKnownInstanceType. It's in
> the link Jose posted.
>
> Thanks,
> Jason
>

> On Thu, Aug 5, 2010 at 12:27 PM, Vadim Chekan <kot.bege...@gmail.com> wrote:
> > On Aug 4, 2:43 pm, Jason Dentler <jasondent...@gmail.com> wrote:
> > > IMO, keeping entities around for the lifetime of the app is bad
> > architecture
> > > regardless of your ORM choice.
>
> > Love it when you judge design even before you know what are the
> > requirements ;)
>
> > How about all kind of dictionaries: list of countries, time zones of
> > the worlds, names of world currencies? How frequently do you want to
> > re-load time zones from DB? At the same time Daylight Time do change
> > from time to time and you can not hardcode it. For some applications,
> > let's say desktop it is perfectly valid assumption that time zone does
> > not change during application life time.
>
> > Vadim.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .

[Vadim Chekan]

Jason,
Not really. As it turned out, caching perfectly solves Huge's problem
(at least one).

WellKnownInstanceType if I understood the posting correctly requires
application recompilation every time country or its info has changed.
If may or may not be an appropriate solution depending on
requirements.

Vadim.

On Aug 5, 1:07 pm, Jason Dentler <jasondent...@gmail.com> wrote:
> Vadim,
>
> Let's review:
>
> User: "I have [x] problem"
> Volunteer: "Are you doing [y]?"
> User: "Yes. How did you know?"
> Volunteer: "We see this all the time. Don't do [y]."
> User: "But [y] works."
> Volunteer: "No, it doesn't. You just said you had [x] problem."
> User: "You're an idiot. [y] is fine. NH sucks."
> Random 3rd Party: "Zomg! [volunteer] is judging [user]'s use of [y] without
> knowing the facts!"
> Volunteer: "Fine. I'm an idiot and NH sucks. Go use Linq2Sql and leave me
> alone."
>
> Like Jason M said, stateful singletons are a recipe for disaster, and any
> entity associated with a session is stateful. It's a fact of NH that can't
> be changed.
>
> btw - For the data you describe, use Fabio's WellKnownInstanceType. It's in
> the link Jose posted.
>
> Thanks,
> Jason
>

> On Thu, Aug 5, 2010 at 12:27 PM, Vadim Chekan <kot.bege...@gmail.com> wrote:
> > On Aug 4, 2:43 pm, Jason Dentler <jasondent...@gmail.com> wrote:
> > > IMO, keeping entities around for the lifetime of the app is bad
> > architecture
> > > regardless of your ORM choice.
>
> > Love it when you judge design even before you know what are the
> > requirements ;)
>
> > How about all kind of dictionaries: list of countries, time zones of
> > the worlds, names of world currencies? How frequently do you want to
> > re-load time zones from DB? At the same time Daylight Time do change
> > from time to time and you can not hardcode it. For some applications,
> > let's say desktop it is perfectly valid assumption that time zone does
> > not change during application life time.
>
> > Vadim.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .