As an anecdotal note, I'm part of a multi-platform company that builds
both desktop and web applications based on AR. Desktop applications
have been the largest part of what we have produced, creating over 30
AR desktop applications. We've been using AR, but we have to maintain
our own custom version to support the client profile. Surely other
people have the same issue. This wouldn't be such a large concern,
but we have a modelling product that we wish to generate AR models
for. When providing users with libraries to use with the modeller, it
would be better if we could point them to the untouched libraries for
use within either scenario.
AR / NHibernate traditionally haven't focused much on usability in the
rich client world, and have stronger web capabilities. Because there
is a barrier to adoption in the client world, the level of adoption
naturally goes down. This will be even more of an issue now that
VS2010 defaults many project types to the client profile. While I
don't really agree with Microsoft's decisions around the client
profile, they have made it an important force in the .NET world.
Windows machines on automatic updates will only install the .NET 4
client profile automatically. For people that wish to distribute apps
to a wide audience, it's a significant concern.
Regarding the IFDEF solution, consider if you have a library such as
Common.DB that links with ActiveRecord. Are there good strategies
available for dealing with situations where both web apps and client
apps wish to utilize Common.DB?
AR basically uses the web portion for linking sessions, but it's
certainly very useful without the web. In fact in our usage of AR we
have never even utilized the built-in web classes, not even when we're
using it with web sites (we have our own scope system for rich client
apps that we also use on the web).
Hope that didn't sound too much like a rant. :)
Patrick Earl
2010/8/30 Henry Conceição <[email protected]>:
> About the split: I think that doesn't makes sense. AR is mostly used
> on web applications, and doing this split would be a useless breaking
> change to the majority of our users.
>
> Maybe an ifdef (excluding the non supported classes/features) can do the
> tricky.
>
> Cheers,
> Henry Conceição
>
>
>
> On Mon, Aug 30, 2010 at 9:19 AM, Michael Maddox
> <[email protected]> wrote:
>> I'd like to see Option 1 happen (split non-client profile code off
>> into Castle.ActiveRecord.Extended).
>>
>> Option 2 feels like it would cause confusion for users.
>>
>> Michael Ketting's blog post mentioned by Fabian seems more like a
>> workaround after the fact than a fundamental solution. It's a useful
>> workaround, but I wouldn't want to encourage it's use when better
>> options are available.
>>
>> -Michael Maddox
>> http://www.capprime.com/software_development_weblog/
>>
>> On Mon, Aug 30, 2010 at 1:47 AM, Patrick Earl <[email protected]> wrote:
>>> Hi all.
>>>
>>> With NHibernate now supporting the client profile, I'd like to see
>>> client profile support for Castle.ActiveRecord. Unfortunately, as far
>>> as I can see, there's no easy way to do it. SessionScopeWebModule is
>>> an IHttpModule and people configure it by providing the qualified
>>> class name in the httpModule section of the config file. I don't see
>>> how to fix that without moving SessionScopeWebModule to a separate
>>> assembly or using compilation directives. For comparison, NLog has
>>> gone through a similar process and split the web components into a
>>> NLog.Extended to match the split between the client and extended
>>> frameworks. I'd like to suggest a couple possibilities.
>>>
>>> 1. Split off at least SessionScopeWebModule (and potentially other
>>> web things) into a Castle.ActiveRecord.Extended (or
>>> Castle.ActiveRecord.Web) assembly. This would be a breaking change
>>> requiring certain web users to add a reference to the new project.
>>> 2. Use #ifdefs and distribute two different versions of the
>>> Castle.ActiveRecord assembly. One for web, one for not.
>>>
>>> My personal preference is #1, since it is a one time change, even if
>>> it's a breaking change. The second one causes all sorts of
>>> distribution / build headaches as mentioned in my other message
>>> pertaining to Castle.Core.
>>>
>>> What are people's thoughts on this?
>>>
>>> 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.
>>>
>>>
>>
>> --
>> 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.
>>
>>
>
> --
> 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.
>
>
--
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.
