I'd love to see a blog post on this... I'm treading similar water developing
extensible applications in monorail.  I might start blogging about my
experiences soon, just so I can get some feedback on our current approach
and ways to improve it (especially around MEF + IOC Container, and
approaches for handling disabling/removing plugins are runtime - something
we currently do have working, but it's not pretty).

Cheers,

 - Alex


On Tue, Feb 23, 2010 at 7:22 AM, hammett <[email protected]> wrote:

> It's a complicated problem. I can see a few ways to solve. but the
> price is increased complexity. Will try to cover this in a blog post
> given that the topic is open ended extensibility..
>
> On Mon, Feb 22, 2010 at 8:44 AM, Jan Limpens <[email protected]>
> wrote:
> > Hello!
> >
> > I have an administrative interface done in MR for a single client doing
> all
> > kind of crud and more operations using explicit services and or explicit
> or
> > implicit Daos (IArticleDao and IDao<Article, long>) resolved from
> Windsor.
> >
> > Now this project has grown and I will have to make this application
> > extensible (and am breaking my head over how to attack this). Different
> > tenants will have different extensions to the base domain. For instance a
> > customer who sells cakes will need different properties on their Article
> > implementation than customer who will sell toys. Domain and NHibernate
> wise
> > I think I've got this handled.
> >
> > From what I see I will have to take care of the full implementation of a
> > certain feature crossing typical layers. So one new feature concerning
> one
> > or a set of changes to the domain model should take care of
> >
> > View and view logic in JavaScript and brail
> > Controller extensions to the base Controller
> > Service extensions...
> >
> > in the form of one dll - in the ideal case - dropping it in a certain
> place
> > should autowire it somehow, but this can wait.
> >
> > What I really am concerned about are the extension points I can provide
> from
> > the administrative interface.
> >
> > A simple case:
> >
> >         [return: JSONReturnBinder]
> >         [Transaction(TransactionMode.Requires)]
> >         public virtual IList<SimpleArticle> FullTextSearchAsJson(string
> > fragment, int categoryId, int productGroupId, string orderBy,
> >
> >  SortDirection direction, int maxResults, bool isActive, decimal from,
> > decimal to)
> >         {
> >             Func<Product, object> func = null;
> >             switch (orderBy.ToLowerInvariant())
> >             {
> >                 case "name":
> >                     func = (x => x.Name);
> >                     break;
> >                 case "id":
> >                     func = (x => x.Id);
> >                     break;
> >             }
> >             var priceRange = new PriceRange(from, to - from);
> >
> >             var articles = articleDao.Find(fragment, categoryId,
> > productGroupId, 0, func, direction, maxResults, 0, isActive, priceRange);
> >             var result = articles == null ? null : new
> > List<Product>(articles);
> >             if (result == null) return null;
> >             var link = new LinkHelper(Context);
> >             return result
> >                 .Select(article => new SimpleArticle(article.Id,
> >                                                      article.Name,
> >                                                      article.Key,
> >
>  link.Article(article)))
> >                 .ToList();
> >         }
> >
> > now we extend the Article class with Properties string ISBN { get; set; }
> > and bool HasISBN { get; } and it becomes the BookArticle class. The above
> > method should also output those two fields.
> >
> > So to have code reuse,
> >
> > I'd probably refactor out the actual query part,
> > taking the dao as a parameter,
> > returns my new article sub class
> > and the I'd use an extended SimpleArticle to present my items.
> > luckily there is no real view involved, because I have absolutely no idea
> on
> > how to introduce code reuse in that area. I wished, my entities
> > automagically would create their forms for themselves, but this cannot
> work
> > for more complicated entities, I suppose.
> >
> > While all of this certainly is doable, it is very non-frameworkey and I
> hate
> > all the coupling this introduces. And the best bet for code reuse in the
> > view area for now is relying on the merge feature of my source control.
> >
> > Anyone wrote something clever about this? Or is inclined to pass me some
> > good pointers here and now?
> >
> > Thanks!
> >
> > --
> > Jan
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Users" group.
> > To post to this group, send email to
> [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<castle-project-users%[email protected]>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/castle-project-users?hl=en.
> >
>
>
>
> --
> Cheers,
> hammett
> http://hammett.castleproject.org/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Users" group.
> To post to this group, send email to [email protected]
> .
> To unsubscribe from this group, send email to
> [email protected]<castle-project-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/castle-project-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" 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-users?hl=en.

Reply via email to