We have a project and I was thinking if the CSLA framework can be removed from it. Is this possible without destroying the core features of the system or would you recommend ground up development, thank you.
Why would you want to do this?
My guess is that you have no understanding of what this frame work does.
Hey Plum,
I'm just following orders, please understand first what we are trying to do before you jump to a conclusion :D
Louie,
I understand you are just investigating what you've been asked to investigate. Really though, I don't understand the blind need for POCOs. To mean that means, as Rocky said, you need to roll your own for everything Csla already provides. And to what end? I've heard "the business layer is the most important, and so it shouldn't be tied to one particular framework." Frankly I think it's a rather bogus arguement. The whole time you're rolling your own, you're also maintaining it, have no real support for it and paying any real costs. And for what? I can't fathom the answer.
Andy
There is no realistic way to remove CSLA from a business library, because all your business types will be subclasses of CSLA base types.
Additionally, if you don't inherit from CSLA base classes, you'll find that none of your data binding works correctly. To my knowledge there are no other frameworks that provide complete support for data binding across all the UI technologies, so (assuming you are using data binding) you'd need to reimplement all those features of CSLA.
Also, if you are using the business rules features of CSLA, you'll have to invent a similar business rules engine.
The same is true for authorization. If you are using that feature you'll have to invent a similar authorization solution.
Finally, if you are using the n-tier data portal functionality, you'll need to reinvent that, or rearchitect your system to use a different model for interacting with your data access layer.
Wow.. thanks for that explanation, very well said. I will relay this to my collegues :D
Copyright (c) Marimer LLC