How is the business layer defined in the IBuySpy Portal? I see that most of the 'components' are data access components, but I dont see any clear pattern in how the business rules are coded throughout the application.... is it all mixed up with the Presentation Layer? the ASPX pages code-behind?

---

"Never argue with an idiot; He will drag you down to his level and beat you with experience"

Are you looking for ASPNetPortal namespace or a batch file who compiles all BL into one DLL?

---

Best regards,

Ivan Andrade

no, im looking for a conceptual design to better understand the architecture

---

"Never argue with an idiot; He will drag you down to his level and beat you with experience"

javiquillen:

If you haven`t yet, aim your portal at http://yourportal/docs/docs.htm

You will notice that the only class referenced as a Business Component is AdminDB.

Although each Module has a primary class which is also viewed as above.

If you did not find this to be enough you could try: Portal WhitePaper

Hopfully helpful to you!

Nemi

---

You're fine! How am I?

I was trying to explain specifically about some characteristics of business layers - more information you can find on IBS documention folder (some relationship are shown between files, SPs, tables, BLs.. ) or try to look at tree design (if you are working with VS.net)

I'm new on .NET development so I'm having a hard work to understand all IBS - view post 230825

---

Best regards,

Ivan Andrade

This is one area where IBS is lacking - it does not really have a well defined business object layer separate from the UI layer and separate from the DAL (data access layer).

In most cases, the UI layer works directly with the DAL. For example, there is no "clean" class for a PortalModule. There are some properties embedded in the ModuleSettings class, some methods embedded in the Security class, some in the Admin classes, etc. This is also true for tabs, users, portals, etc.

Also, for the modules, it would be nice, i.e., better design, to have, for example, an Announcement class that encapsulates the properties and methods for an Announcement in addition to the AnnouncementDB class that provides the basic DAL. Using this approach, you could have several UI components/controls that allow the user to interact with Announcements but just one Announcement class.

In my own code, I've started to define proper classes, e.g., PortalModule, PortalTab, PortalUser, etc. When I'm done, this should yield a more flexible and durable architecture.

---

Mike Beller

Lightship Partners LLC

Hi mbeller,

I too have been working on breaking out the 3 tiers in my own recent developed inspired by IBS.

I would be interested to know if it is a best practice to combine business and data access in the same class when working with objects that truly encapsulate their logical meaning, like PortalSettings for example. Everything I have read about n-tier developed suggests that combining the two (as MS wittingly does within the class cs file appending a DB suffix) is not a true seperation of the two.

So, being relatively new to true OO programming and knowing that IBS is a reference and should not be taken 100% literally, my approach has been the following:

(Psuedo Code of course)

==============
YadayadaBiz.cs
===============

namespace MyCompany.YadayadaBiz

// Lives in its own cs file for org purposes

public class PortalSettings
{
// properties
string propertyName;

PortalSettings()
{
propertyName = YadayadaData.PortalSettings.GetPropertyName();

}// end constructor

} // end class

=================
YadayadaData.cs
=================

namespace MyCompany.YadayadaData

// Lives in its own cs file for org purposes

public class PortalSettings
{
public string GetPropertyName()
{
//Sql Plumbing

SqlDataReader dr = command.ExecuteReader();

return dr[0].ToString();

} // end data access method

} // end class


Am I on the right track here?

Thanks,

Rick