implementationpresentation-layerdata-layer

drawbacks for implementing presentation layer inside data layer


whats the drawback in implementing the presentation layer inside data layer. i guess that would be much dynamic and performance oriented way to go for, for example if i compile to code (i mean full compile where even aspx is compiled) and after that i need to make some design changes, i dont need to update of compiled library i can make the changes directly here.

Please correct me if i am wrong.

Here's the link where someone posted it as a drawback.


Solution

  • haven't logged-in for a while or i'd have answered you sooner.

    just going off the top of my head...

    1. by putting static data into the stream between your application, and your database, you're increasing the load on your database, and possibly increasing traffic. Your database isn't needed to process this, and your application won't have to do any less work, so there's a loss, but no gain.

    2. your ide (visual studio, etc.) for your app gives you some great features -- validation, intellisense, etc. for these html controls, whereas your database does not.

    3. You're right about not needing to update your compiled app if you use the database approach, but that's both a good and a bad thing. the good part is, it's easier for you not to have to re-complile. The bad part is, you're pushing testing for all of your updates to the database code out to the application runtime, and losing a lot of nice debugging features your ide has in the process. You should try to catch these kinds of errors lot earlier in the lifecycle.

    and so on...

    I think if you're just doing some small-time stuff, and don't have a lot of traffic or critical processes, then you'll be alright doing it in the database. But as inconvenient as it is, if you ever need to get more serious with testing/debugging, application up-time, heavier traffic, or other increased demands, re-compiling is going to work a lot better for you.