Hi all,
I know the immediate answer is NO !
Yea, Yea, I know that if I want my class to be able to inherit from serviced component and be able to work well in com+ transaction I'll need to be able to instanciate an object.
But in my case, I have a business workflow layer, which handles the transaction (using the new TransactionScope class - wonderfull class !! try it !!), so I don't see the need to instanciate a BLL and DAL, and they can just act as helper classes with methods that receive and instance of an entity (it's state) and handle it accordingly.
BTW, the workflow layer is object based (not static, didn't know exactly how to write it).
Any opinions am I missing something
Awaiting for further instructions ...
Ido.
Define BLL and DAL as static classes ?
James Gordon
Hi Ido,
I am on the domain modeling camp so I would not separate my entities from their BL which gives you what Martin Fowler calls an Anemic Domain Model (but don't let me make you feel too bad about it as what you are doing is considered a good practice by many, MS included - Never the less you may still want to look at http://domaindrivendesign.org/ ) -
Anyway, I think it is a good approach to feed your entities to DAL or any other extending objects - this is what Alistair Cockburn describes as Hexagonal Architecture which gives you a lot of flexebility.
I would probably not instantiate these as static classes since this really would make it way too procedural programming for me
Arnon