Yes, this is mostly correct. However, we do both. So, we're involved with large scaled applications as well. Naturally, these applications require a different approach than one-off type applications.

The reason I posted about applications where I don't care *too* much about proper design is this post: You are NOT inadequate. I often feel that proper, n-tier design is made so abstract by those discussing it, that the ones with less knowledge about the subject can't follow along and decide not to implement proper design at all. This way, the "ones in the know" tend to keep the knowledge to themselves too much.

The net result of this is that the ones who know how to do it can create beautifully designed applications, while the rest is left behind with the SqlDataSource and no idea why that is not the most recommended object to use, or how to improve it.

The reason behind my upcoming n-tier articles is to make it easier to understand basic design principles in web applications, making the concepts more accessible for everyone. The idea is to present a concept that can easily be followed by many programmers, and that is not that much harder to understand and implement that using stuff like the SqlDataSource controls.....
It may not be the best or the most pure or the most clean way to do things from OO or other perspectives, but it works and should be relatively easy to understand.

Regarding design guidelines, take a look at the book Framework Design Guidelines. This is largely Microsoft's internal guidelines published as a book. It deals with a broad set of subjects, including naming guidelines.

Regarding binding: binding doesn't work well with custom objects. Displaying it is OK, getting it back again when posting back isn't because .NET doesn't know how to recreate the object.

Something like this should work fine:

Eval("YourNameValueInstance.Name")

This thread is now discussing three subjects: n-tier design, coding guidelines and binding complex objects. My suggestion is to keep this thread to n-tier design. Please start a new thread if you want to post follow up for the other topics.

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.

 

I agree that design/architecture related issues are made so abstract that it is difficult to follow.

What according to you is a good design and how you implement it? In answer to this I will be waiting to read your article :). At least you are not keeping that knowledge to yourself, your a good man.

Tahir

Peter,

You work with BO, BLL and DAL. Between these layers how one layer calls the other. e.g. if UI needs a list of Products will you say something like

(Directly calling DAL from UI)
UI: Products = ProductsDAL.GetList()

or

(Calling BLL from UI which in turn calls DAL)
UI: Products = ProductsBLL.GetList()
BLL: return ProductsDAL.GetList()

In other words does each layer (UI, BLL, DAL) calls only the layer below it, as in, UI calls BLL, BLL calls DAL or can UI call DAL?

Tahir

Short version: the BO + Bll + Dal design we talked about earlier. Peter explained this in more detail. Also, it's a design that comes close to what I used for the BugBase and other applications in my book and that you call(ed) SOA.

Longer version: you have to wait (as in quite long as I don't have much time right now) until my articles are finished... ;) Do you see now why I urged you to post this on the Wrox forum instead of discussing this through a private e-mail conversation? The public post has generated a lot more interest (with Peter's contribution and over 180 views) than a private conversation would have....

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to: Forest Fire by Dead Kennedys (Track 6 from the album: Plastic Surgery Disasters + In God We Trust) What's This?

Imar,

Same question for you as well

You work with BO, BLL and DAL. Between these layers how one layer calls the other. e.g. if UI needs a list of Products will you say something like

(Directly calling DAL from UI)
UI: Products = ProductsDAL.GetList()

or

(Calling BLL from UI which in turn calls DAL)
UI: Products = ProductsBLL.GetList()
BLL: return ProductsDAL.GetList()

In other words does each layer (UI, BLL, DAL) calls only the layer below it, as in, UI calls BLL, BLL calls DAL or can UI call DAL?

Tahir

IMO, yes, UI calls BLL, BLL calls DAL but UI doesn't DAL directly.

The idea of the business layer is to enforce business rules, including security checks.

So, the business layer could decide that you can't call ProductsDAL.GetList() because today it's Friday, or because your name isn't Joop or because you aren't in the Administrators roles.

The BLL is responsible for that, so if you let calling code access the DAL directly, you bypass the Bll's responsibility, leading to all kinds of issues.

Basically, this is what the SqlDataSource controls do. They talk to the database directly. This often leads to a lot of code, a lot of unsecure code, and a lot of difficult to manage and maintain code.

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to: Vent by Tricky (Track 1 from the album: Pre-millennium Tension) What's This?

But what about you BTW??

You ask a lot of questions, asking for other people's opinions and ways they work. But what do you think yourself? How do *you* design your applications? What's your opinion about everything we discussed so far?

You said you turned down a job as a software architect. If you're asked for such a job, I am sure you must have some background and ideas about this?

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to: Second Sight by Placebo (Track 10 from the album: Sleeping with Ghosts) What's This?

Imar,

I am a Software Development Manager in a company that specialise in developing Payroll Bureau/HR related products for Accountants and other companies. I was offered a role of Architect because of the success of one of the product that I managed/developed. I turned it down because I am happy with what I am doing plus I dont feel that I have the ability to be an architect. My main areas of interests are Software Processes and my current role suits that. I have interests in Software Architecture, which is why I am here discussing with you fellows about this.

I believe that it is more important to keep things simple. It is more important to follow a methodology that will help you achieve the end taks i.e. software product. Our end goal is to create software that is loved by the client and I have yet to work with a client that cares what 'Architecture' we use. It is important to remember that things like Architecture, Design, Patterns etc are for the software development team and not for clients. Clients will want a product that provides value to their business. As long as your software provides that, they will be happy.

In terms of design that I use is similar to what you and Peter have described here. That is why I was interested in having these discussions with you. I use following architecture: Start with Domain Model converting into Design Model where a Domain object will split in Entity, Business and Data. e.g. Employee will be realised in EmployeeEntity, EmployeeBusiness and EmployeeData. I find this configuration very flexible over other choices. Namespaces will then become Entities, BusinessServices, DataServices. The 'Services' word does not come from SOA, but from the concept that each object is performing a service (or a Service is being performed on that object) within the context of the application.

The Payroll Bureau Management System our team has developed is HM Revenue & Customs accredited product that is being introduced to Accoutants in UK, competing with Sage Payroll. It was a medium-large scale project and I have used same concepts in this project which had tons of very complex Business Rules related to payrolls.

Tahir

Imar/Peter,

Another interesting question!

We have UI, BO, BLL and DAL. The way in which they communicate is linear i.e. UI -> BLL -> DAL or DAL -> BLL -> UI. Now the question is that how do one set of BO, BLL and DAL communicates with other. e.g. if we have a CustomerBLL and InvoiceBLL, and there is a scenario where we need both of them then CAN these BLL's talk with each other?

In other words can a BLL call another BLL?

How do you tackle such scenarios?

Best regards,

Tahir

Like Imar's reply, I rely on the BLL to handle all UI requests. In many cases, the BLL just plays middle-man, and passes requests on through to the DAL. But the plumbing is in place to add more logic within the business logic class.

I see this as an important aspect of the n-layer design because we can modify any layer to work differently without needing to change another layer. For example:
1. I could change the UI to call all business objects through remoting on another server. BLL & DAL don't change, they just move.
2. I could change data access layer to use a different data store. UI & BLL don't need to care.

-Peter