Just as there's assemblies like
Castle.Logging.Services.NLogIntegration and
Castle.Logging.Services.log4netIntegration (since not everyone wants
to use log4net or NLog), for the sake of argument does it not also
make sense to have Castle.Logging.Services.WebIntegration (since not
everyone wants that either)? Though there was no split originally,
there is now a division and I believe Web should be treated as any
other component which people don't necessarily have.
To be clear, I am also willing to do the work to split AR into two
distributions. At least there would be official versions to point
people to, even if they are inconvenient to utilize. For our company,
since we use both the client profile and web with shared libraries, we
will continue to internally patch the ActiveRecord source as we have
always done. We don't want to have the added expense of coming up
with a system to use one dependency chain for one project and another
dependency chain for another.
For example, doing this is not easily supported by VS:
[The arrow indicates a reference. The indentation of the arrow shows
which project is referencing the dependency.]
WpfApp
-> Common.Database.Wpf
-> Common.Database (client)
-> ActiveRecord (client)
WebApp
-> Common.Database.Web
-> Common.Database (client + extended)
-> ActiveRecord (client + extended)
But, doing this is:
WpfApp
-> Common.Database.Wpf
-> Common.Database
-> ActiveRecord
WebApp
-> Common.Database.Web
-> Common.Database
-> ActiveRecord
-> ActiveRecord.Web
Believe it or not, I do generally expect assembly divisions along
major framework alternatives. If you're building a web application,
it's pretty easy to include assemblies related to web stuff. It's
easy to understand that I don't need the WPF or WinForms assemblies
also. It may seem like a proliferation of assemblies, but when the
developer has to pick them, they pick one line that matches their
requirements. For example, I want to use NLog in a WPF app. I pick
the cores, then pick assemblies that are related to NLog and WPF.
Usually frameworks don't need to split too many ways since they're
usually working in one area or another. For example, NLog only split
on Web vs Core.
This pattern of "core assembly + integration assemblies" is very
common. Take these examples:
Castle.Core + (Castle.Logging.Services.Log4NetIntegration,
Castle.Logging.Services.NLogIntegration)
NLog + (NLog.Extended)
NHibernate + (NHibernate.ByteCode.*)
Granted, when additional assemblies can be avoided using relflection,
this is often an easier approach. Sadly, there is one class in AR
that doesn't allow for that. The good news though is that Castle.Core
can provide the best of all worlds, at least simplifying the
distribution of things like NHibernate.ByteCode.Castle.
Patrick Earl
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
