COMMENT: NUWANDA

MAY 8, 2008 - 00:03:08

» I've shed a few tears recently trying to figure out a solid .net architecture that looks good from A-Z. I'm no expert but your architecture looks really maintainable, scalable, readable, fast and each layer is friendly to use. I'm thinking about alot of things after reading(skimmed through some parts, saving the full read untill a long flight later in the week :) your article, as I say'd I'm just a beginner so hopefully you will bear with me if my questions are silly. I'm wondering about the Linq to Sql part, is that inhibiting you in any way? compared to using ado.net in the data layer, and the linq objects, always transforming them to custom objects how is that effecting performance, wouldt it be faster with using a datareader? And using dumb classes, that couples the data access layer to the domain model alot, agen passing a .net framework class(datareader) from the DAL to the BLL would maybe be better? Also with this architecture, with the GetList() method for example....you need one gridview and one ObjectDataSource and one page for each *Manager class, to display all your lists. If you have 100 lists this might be bad practice? Is there a way(inheritance/polimorphism/factory pattern) to be able to only use one gridview and one ODS in one page to display all the lists. If you know from a value on the page which *Manager GetList() method to use.

Since this is not a support forum I've said more then anough already :) Thank you agen for this excelent article.

Nuwanda « «

COMMENT: FERDY

MAY 8, 2008 - 03:39:35 PM

» Nuwanda,

Thanks for your compliments and detailed response. Hereby a few answers from my side:

- concerning the conversion of LINQ object to custom data objects: There are different ways to do this, for example you can directly bind from controls to LINQ classes, or you can define an intermediate layer like I did. The advantage of an intermediate layer of objects is that you have a neutral layer, the disadvantage is that it requires some manual steps to keep them in sync. There is no single best practice, you have to make this choice yourself.

- I have not tested the performance difference between data readers and LINQ data access, but in many modern applications, the difference is probably so tiny that nobody would notice.

- It is true that in my architecture the Data Access layer has to know about the dumb Business Objects, but the same applies if we would not have these dumb objects. In that case, the business layer would talk directly to the LINQ classes, and would have to know about those too. What if the data access layer changes? «

COMMENT: GANAPATHIRAM NATARAJAN

MAY 9, 2008 - 10:11:41 AM

» This is great Ferdy! «