OK so given the complex types of designs you can architect/develop, things are getting a little too confusing.
So for example, say we have a 3 Tier Arch:
UI
BLL
DAL.
The UI only ever needs to pass in data to the BLL to work with and depending on the type of method in the BLL, it returns back a result of a complex type or a simple type (i.e bool for success/fail)
The BLL, in the constructor at least in my solutions, is responsible for creating the DAL such as CustomerDAL or OrdersDAL. Great
The problem here then becomes testability and extensibility. It means you cannot swap in or out your BLL for a completely different implementation of business domain logic or even your DAL.
The DAL is slightly easier in this case because you could implement an interface type which then any type of CustomerDAL can use and then the BLL would be the one to decide what kind of underlaying concrete it wants to use in terms of the implementation
for the DAL but only ever uses that interface throughout the rest of the BLL. Example:
public MyBLL()
{
ICustomerDAL cDAL = new CustomerDALA(); // (or: ICustomerDAL cDAL = new CustomerDALB();)
}
Fine.
But what about the BLL itself? i mean, the UI would of course need to instantiate the BLL But how would you swap in/out the BLL? Sure its easy because it is just one line change of code so instead of using MyBLL they could use MyOtherBLL. The problem here
then is if the signatures and methods change in the new BLL, the UI needs to alter itself - that could be fine depending on the design change but then it may not be.
You could use the same type of approach for the BLL and DAL relationship in the UI but I still think it "smells".
So really the question is, what is the right or rather best practice here to architect/design your n-tier solution so it is easy to do things like swapping in or out your tier components without major code breaks?
I know you can probably use IOC/DI but I really don't feel that strong about it because all you are doing is have an interface contract guarentee to map to a concrete type and use the interfaces which is a good thing (de-coupling/loose coupling) but I still
dont quite understand how that would help? Maybe I am mis-informed or confusing myself as I keep reading different articles online.
in my designs, I DO NOT like the idea of have a constructor for the BLL to take a DAL as a parameter. the UI should never do this - it should only care about creating the BLL and calling its methods, everything else under the hood/dependencies from the BLL
layer would be constructed and managed by the BLL Constructor such as instantiating DAL's or webservices etc...
Many thanks and sorry for the long and confusing post - as you can tell, I am confused!
So, just for the sake of architectural discussion, there is nothing magic about the 3 tier. You can implement as many tiers as required. Remember to use Occams' Razor and keep things simple.
2 tier, 3 tier, n-tier - depending upon the needs of the application are all valid implementations.
Sure but that doesnt quite answer my question at all. I used 3 Tier as a simple example - thats all. OK so I could have changed 3 to an "n" instead. But thats not really the question :)
I don't see what you have against IOC. It's exactly what you need for these purposes. Your BLL doesn't create the DALs, it hold public proeprties for interfaces to them, and the IOC container creates the appropriate object as needed. If you want to swap
something, it's very simple and doesn't alter the BLL itself (which is the way it should be).
Also, you get the benefit of being able to test the BLL without database dependencies, making the tests more deterministic. You can set up fixed static data for the tests, and have the DAL stub return those, so your tests can be confident about what the
"DAL" is going to do, leaving you free to test the BLL code.
As far as the BLL constructor have aparameter for the DAL, what's the problem? If you are using an IOC container, that passes in the DAL for you, so you are no longer tying your code to specific DAL implementations. Only the IOC container itself knows what
type of objects it will be creating (and you have to specify this somewhere, it can't happen by magic!), leaving the rest of the code ttally agnostic to the implementation of any other layer.
Unless I missed something, you already have the answer.
Hope this helps.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
Thanks. I'm not for or against IoC I just dont understand why the complication at times.
I disagree with your statement that the BLL should have a public property which injects a DAL instance because then the UI would get access to the DAL indirectly.... it shouldnt expose such information :-)
Now if it were a private property then yeh ok, I understand that. IoC also can be difficult to maintain in the future, so really it should be some form of a ServiceLocator perhaps.
Thanks. I'm not for or against IoC I just dont understand why the complication at times.
I must say that I used to think that IOC was a complication until I started using it. I now think of it as exactly the opposite. It frees me from worrying about what objects are floating around in each layer. I work with the interfaces, and leave the actual
object instantiation to the IOC container.
It certainly makes life a whole lot easier when it comes to unit testing.
ahmedilyas
I disagree with your statement that the BLL should have a public property which injects a DAL instance because then the UI would get access to the DAL indirectly.... it shouldnt expose such information :-)
I wasn't saying you have to have a public property, and in the case of a DAL, it's probably makes more sense to have it as a constructor parameter, as it's a requirement for the BLL. That removes your concern about the UI being able to access
the DAL directly (which is an interesting point that I have never thought of before, and never seen discussed in all the books and articles I've read on the subject).
ahmedilyas
Now if it were a private property then yeh ok, I understand that. IoC also can be difficult to maintain in the future, so really it should be some form of a ServiceLocator perhaps.
Why do you think IOC is difficult to maintain? I haven't found that. To the contrary, all the object binding is in one place, making it easy to maintain. On the contrary, a service locator puts a certain amount of the object binding in the classes themselves,
whereas the IOC container removes it completely. Also, the IOC container (depending on which you use, but generally speaking) will auto-wire the dependencies for you, whereas with a service lcoator, you have to do it all yourself. Sounds like a lot more work
to me.
Obviously, there are no fixed answers, and what works for one person may not work for another. For that matter, what works for one project may not work for another, it's a matter of seeing what is best for the specific circumstance, but my experience is
that for all but the smallest of projects, IOC provides great gains for little extra effort.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
good points. And I agree and believe I said it in my original post where there is no "one size fits all" type of solution at all.
So, can you give an example of the following:
a simple 3 Tier architecture which uses an IoC design and a simple call from the UI to the BLL to GetCustomerById which returns a DTO back to the UI and is bound to the screen just showing firstname and lastname?
basically, it would be nice to know how you do it and why you do it in that certain way. It would also expose how you use the IoC..... :-)
The IOC part is really down to which IOC container you use. I use Ninject, which requires adding the appropriate Nuget packages to the project. This adds a class to the project that sets up the injection, leaving me with the simple job of binding my dependencies
to the appropriate interfaces...
That's all there is to it at this level. In the code above, I'm binding WCF services, but you could just as easily bind a BLL that is referenced in a local assembly. From that point on, all your UI layer code needs to do is declare any interfaces it wants to use...
[Inject]
public SupportService SupportService { get; set; }
...and then you can just use the injected object as if it were locally created.
As for what the BLL returns, that's really up to you. If it returns a DTO, that's fine. Screen binding is then just standard MVC stuff, which you can see in the tutorial videos, or in any of the code samples around.
I hope that helps.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at http://dotnetwhatnot.pixata.co.uk/
ahmedilyas
Member
414 Points
586 Posts
N-Tier architecture
Dec 25, 2012 12:49 PM|LINK
Hi all, Happy Holidays!
OK so given the complex types of designs you can architect/develop, things are getting a little too confusing.
So for example, say we have a 3 Tier Arch:
UI
BLL
DAL.
The UI only ever needs to pass in data to the BLL to work with and depending on the type of method in the BLL, it returns back a result of a complex type or a simple type (i.e bool for success/fail)
The BLL, in the constructor at least in my solutions, is responsible for creating the DAL such as CustomerDAL or OrdersDAL. Great
The problem here then becomes testability and extensibility. It means you cannot swap in or out your BLL for a completely different implementation of business domain logic or even your DAL.
The DAL is slightly easier in this case because you could implement an interface type which then any type of CustomerDAL can use and then the BLL would be the one to decide what kind of underlaying concrete it wants to use in terms of the implementation for the DAL but only ever uses that interface throughout the rest of the BLL. Example:
public MyBLL()
{
ICustomerDAL cDAL = new CustomerDALA(); // (or: ICustomerDAL cDAL = new CustomerDALB();)
}
Fine.
But what about the BLL itself? i mean, the UI would of course need to instantiate the BLL But how would you swap in/out the BLL? Sure its easy because it is just one line change of code so instead of using MyBLL they could use MyOtherBLL. The problem here then is if the signatures and methods change in the new BLL, the UI needs to alter itself - that could be fine depending on the design change but then it may not be.
You could use the same type of approach for the BLL and DAL relationship in the UI but I still think it "smells".
So really the question is, what is the right or rather best practice here to architect/design your n-tier solution so it is easy to do things like swapping in or out your tier components without major code breaks?
I know you can probably use IOC/DI but I really don't feel that strong about it because all you are doing is have an interface contract guarentee to map to a concrete type and use the interfaces which is a good thing (de-coupling/loose coupling) but I still dont quite understand how that would help? Maybe I am mis-informed or confusing myself as I keep reading different articles online.
in my designs, I DO NOT like the idea of have a constructor for the BLL to take a DAL as a parameter. the UI should never do this - it should only care about creating the BLL and calling its methods, everything else under the hood/dependencies from the BLL layer would be constructed and managed by the BLL Constructor such as instantiating DAL's or webservices etc...
Many thanks and sorry for the long and confusing post - as you can tell, I am confused!
madflatpicke...
Member
301 Points
67 Posts
Re: N-Tier architecture
Dec 25, 2012 05:51 PM|LINK
So, just for the sake of architectural discussion, there is nothing magic about the 3 tier. You can implement as many tiers as required. Remember to use Occams' Razor and keep things simple.
2 tier, 3 tier, n-tier - depending upon the needs of the application are all valid implementations.
ahmedilyas
Member
414 Points
586 Posts
Re: N-Tier architecture
Dec 25, 2012 05:58 PM|LINK
Sure but that doesnt quite answer my question at all. I used 3 Tier as a simple example - thats all. OK so I could have changed 3 to an "n" instead. But thats not really the question :)
MrYossu
Member
134 Points
143 Posts
Re: N-Tier architecture
Dec 27, 2012 01:22 PM|LINK
Hello,
I don't see what you have against IOC. It's exactly what you need for these purposes. Your BLL doesn't create the DALs, it hold public proeprties for interfaces to them, and the IOC container creates the appropriate object as needed. If you want to swap something, it's very simple and doesn't alter the BLL itself (which is the way it should be).
Also, you get the benefit of being able to test the BLL without database dependencies, making the tests more deterministic. You can set up fixed static data for the tests, and have the DAL stub return those, so your tests can be confident about what the "DAL" is going to do, leaving you free to test the BLL code.
As far as the BLL constructor have aparameter for the DAL, what's the problem? If you are using an IOC container, that passes in the DAL for you, so you are no longer tying your code to specific DAL implementations. Only the IOC container itself knows what type of objects it will be creating (and you have to specify this somewhere, it can't happen by magic!), leaving the rest of the code ttally agnostic to the implementation of any other layer.
Unless I missed something, you already have the answer.
Hope this helps.
ahmedilyas
Member
414 Points
586 Posts
Re: N-Tier architecture
Dec 27, 2012 03:33 PM|LINK
Thanks. I'm not for or against IoC I just dont understand why the complication at times.
I disagree with your statement that the BLL should have a public property which injects a DAL instance because then the UI would get access to the DAL indirectly.... it shouldnt expose such information :-)
Now if it were a private property then yeh ok, I understand that. IoC also can be difficult to maintain in the future, so really it should be some form of a ServiceLocator perhaps.
MrYossu
Member
134 Points
143 Posts
Re: N-Tier architecture
Dec 27, 2012 09:58 PM|LINK
I must say that I used to think that IOC was a complication until I started using it. I now think of it as exactly the opposite. It frees me from worrying about what objects are floating around in each layer. I work with the interfaces, and leave the actual object instantiation to the IOC container.
It certainly makes life a whole lot easier when it comes to unit testing.
I wasn't saying you have to have a public property, and in the case of a DAL, it's probably makes more sense to have it as a constructor parameter, as it's a requirement for the BLL. That removes your concern about the UI being able to access the DAL directly (which is an interesting point that I have never thought of before, and never seen discussed in all the books and articles I've read on the subject).
Why do you think IOC is difficult to maintain? I haven't found that. To the contrary, all the object binding is in one place, making it easy to maintain. On the contrary, a service locator puts a certain amount of the object binding in the classes themselves, whereas the IOC container removes it completely. Also, the IOC container (depending on which you use, but generally speaking) will auto-wire the dependencies for you, whereas with a service lcoator, you have to do it all yourself. Sounds like a lot more work to me.
Obviously, there are no fixed answers, and what works for one person may not work for another. For that matter, what works for one project may not work for another, it's a matter of seeing what is best for the specific circumstance, but my experience is that for all but the smallest of projects, IOC provides great gains for little extra effort.
ahmedilyas
Member
414 Points
586 Posts
Re: N-Tier architecture
Dec 27, 2012 10:04 PM|LINK
Great discussion MrYossu :)
good points. And I agree and believe I said it in my original post where there is no "one size fits all" type of solution at all.
So, can you give an example of the following:
a simple 3 Tier architecture which uses an IoC design and a simple call from the UI to the BLL to GetCustomerById which returns a DTO back to the UI and is bound to the screen just showing firstname and lastname?
basically, it would be nice to know how you do it and why you do it in that certain way. It would also expose how you use the IoC..... :-)
MrYossu
Member
134 Points
143 Posts
Re: N-Tier architecture
Dec 31, 2012 02:26 PM|LINK
Hello,
The IOC part is really down to which IOC container you use. I use Ninject, which requires adding the appropriate Nuget packages to the project. This adds a class to the project that sets up the injection, leaving me with the simple job of binding my dependencies to the appropriate interfaces...
That's all there is to it at this level. In the code above, I'm binding WCF services, but you could just as easily bind a BLL that is referenced in a local assembly. From that point on, all your UI layer code needs to do is declare any interfaces it wants to use...
[Inject] public SupportService SupportService { get; set; }...and then you can just use the injected object as if it were locally created.
As for what the BLL returns, that's really up to you. If it returns a DTO, that's fine. Screen binding is then just standard MVC stuff, which you can see in the tutorial videos, or in any of the code samples around.
I hope that helps.