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].
> 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].
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en.

Reply via email to