c**t
发帖数: 2744 | 1 There are too many frameworks out there: Miicrosoft P&P; Caliburn... what
are you using? |
l*s
发帖数: 783 | 2 Did some study on PRISM before and think it's good. But for me it's too big a project to be depended on and I would rather to get the ideas or some small part of out of it like the event aggregator.
【在 c**t 的大作中提到】
: There are too many frameworks out there: Miicrosoft P&P; Caliburn... what
: are you using?
|
c**t
发帖数: 2744 | 3 Why do you think CAL is big? a few hundred KB is nothing..
big a project to be depended on and I would rather to get the ideas or some
small part of out of it like the event aggregator.
【在 l*s 的大作中提到】
: Did some study on PRISM before and think it's good. But for me it's too big a project to be depended on and I would rather to get the ideas or some small part of out of it like the event aggregator.
|
l*s
发帖数: 783 | 4 When I evaluate a library, first thing comes to mind is whether it's
maintainable by my own team; Second is how hard is it to switch to another
library;
I am talking about the impact is big but not the size.
some
【在 c**t 的大作中提到】
: Why do you think CAL is big? a few hundred KB is nothing..
:
: big a project to be depended on and I would rather to get the ideas or some
: small part of out of it like the event aggregator.
|
c**t
发帖数: 2744 | 5 the main advantage is seperation, CAL should be easier adopted among group
members. Caliburn auther even suggests all files(include xmal) should less
than 100 lines. If we follow the pattern right, maintainability will become
better.
CAL is designed for fast changing inputs/requirments, for test driven.
However, it's not friendly to appdomains/processes.
【在 l*s 的大作中提到】
: When I evaluate a library, first thing comes to mind is whether it's
: maintainable by my own team; Second is how hard is it to switch to another
: library;
: I am talking about the impact is big but not the size.
:
: some
|
l*s
发帖数: 783 | 6 I understand the main purpose of PRISM is decouple components. And
maintainability of your own code should be better. But that comes a price
that you are totally depends on a open source library(or third party
component) to do a lot of things for you and the question is that whether
this library is too big to fail? The worst case is that if this library's
development ceases, can your team maintain it(fixing bugs) by yourself? or
can you easily use another similar library to replace it? That's wh
【在 c**t 的大作中提到】
: the main advantage is seperation, CAL should be easier adopted among group
: members. Caliburn auther even suggests all files(include xmal) should less
: than 100 lines. If we follow the pattern right, maintainability will become
: better.
: CAL is designed for fast changing inputs/requirments, for test driven.
: However, it's not friendly to appdomains/processes.
|
