Wrox Programmer Forums
Go Back   Wrox Programmer Forums > ASP.NET and ASP > ASP.NET 2.0 > ASP.NET 2.0 Basics
|
ASP.NET 2.0 Basics If you are new to ASP or ASP.NET programming with version 2.0, this is the forum to begin asking questions. Please also see the Visual Web Developer 2005 forum.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the ASP.NET 2.0 Basics section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old February 7th, 2007, 11:30 AM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Peter,

I prefer to keep BO as entities (or dumb). If your UI would need it then something like this would do
CustomerEntity Customer = CustomerData.GetItem(CustomerID);

If there is some business logic to be applied then something like this can be done

if (CustomerBusiness.Validate(CustomerEntity)==true)
{}

or

TaxEntity = PayrollBusiness.CalculateTax(TaxEntity)

Now this way we have Entities, BLL and DAL. However, if I need more complex scenario then I have BusinessProcesses layer as well which will orchestrate various BLL's and DAL's.

What do you think about my approach and what flaws do you see it in?

Imar suggested the book Expert C# Business Objects. I have purchased an e-book and ready few chapters. The concept which author in this book is presenting is that we have ONE object that has EVERYTHING. A lot of work has been delegated to base classes or Data Portal (which is like a facade I guess). However, business logic and data access both are done within one object. With all due respect to the author, I dont understand this concept really. May be its my lack of knoweldge but I think that Two of the most important factors while designing I think are Cohesion and Coupling. The concept that author promoted ruins the idea of Cohesion (one class doing everything). If you have any views on that please let me know.

Lastly I would like to say that I dont mean to criticise any particular concept or any particular person. My aim is to learn and become a better professional. These discussions, I think, are key to that.

I am thankful to you Peter and Imar for taking time out for my queries.

Best ragards,

Tahir

 
Old February 7th, 2007, 03:35 PM
Imar's Avatar
Wrox Author
 
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
Default

While I certainly agree that proper design is something valuable and a good way to build applications, I also have a very pragmatic take at things.

Consider for example the applications from my Instant Results book, like the Wrox CMS, the Appointment Booking application or the BugBase. Those kind of applications are built thousands of times a day all over the world. Where I work we do that as well: we often build moderately sized web sites that take a couple of weeks to develop. These applications often include a lot of custom functionality based on customer input but after release v1.0, they're relatively static.

With these sites, I don't care about the purest form of separation. I don't have to "just switch from SQL Server to Oracle" the same day, I don't get my data from an XML document instead of the database all of a sudden, I don't care about integration with XML Web Services or WCF and actually really don't care that much if my business objects accesses the database directly. In 99 percent of the cases, these sites run on the same physical box as the database anyway.....

What I do care about in these cases is code that's easy to understand by me and my co workers. Code that can be changed by anyone in my team without long architectural sessions in front of a white board to understand the zillion-tier clean design.
This improves time to market, maintainability and makes it easier to hire new people to work on old sites.

That said, a good architecture is a good architecture. The more complex an application becomes, the more important it is to have a scalable solution that can grow with your needs, requirements, demands and knowledge. But either way, I prefer something that works now over something that works on the white board tomorrow.

Take the CSLA framework for example. The whole idea behind it is "mobile objects". For example, you can create an object on your presentation server (e.g. a web site). This object contains data / fields and methods like Save. If you want, you can call Save on the object on the presentation tier, the object is serialized through the CSLA framework, sent to an application server where it's reconstructed and finally it is saved on the application server. Clean, simple, powerful.

True, in this design I have an object that contains data and logic. However, due to the architecture of things, it's not spaghetti. The data is not *mixed* with logic, as classic ASP was. You can still have a clean separation in your code setup, so everyone understands what's going on. At the same time, the benefits of "mobile objects" outweigh the issue of "broken separation". In fact, you can still have separation, because data access code runs at the application or database server, and business logic runs on the business server.

Although a class physically contains the code for the layers, doesn't mean you can't have an optical and even physical separation in functionality.....

I am definitely not a CSLA expert, so I recommend you get the full book and read it all the way through. You may not use the CSLA framework at all, but the book certainly helps you think about architecture.

Just some ideas..... I am sure I am overlooking many things.....

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.
 
Old February 7th, 2007, 03:50 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 2,189
Thanks: 5
Thanked 59 Times in 57 Posts
Send a message via MSN to gbianchi
Default

can I say Hallelujah Imar???? that's one of the best post I ever seen...

and I agree 100% with you about the design...

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
 
Old February 7th, 2007, 05:47 PM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

The reason why I think having a clean design is:

I have seen in my career, which is only 3 years long, that a small product will grow into a medium one and a medium project will grow into a large one. Requirements change, in fact to be more precise they grow. All the project on which I have worked haven grown in size because the customer wanted more and more. In such cases if the architecture of an application is not flexible enough then that becomes a constraint in product's growth.

I agree with Imar that being pragmatic is important. At the same time I believe that by following some of the best practices, patterns and concepts we can design a systems of good quality. I personally dont try to be too clever and just follow a simple pattern of SAP i.e. Simple As Possible :). Simplicity is sometimes flexible then being too smart. Something I learnt while playing Chess :)

I consider software development as an art rather than an industrial process. Why? Because there is no E=MC(sq) i.e. there are no fixed formula's in software development. Patterns, Practices, Architectures, Frameworks etc are all good practices and nothing more. One of the conclusions of my research (regarding software processes) was that 'Common Sense' is one of the most important thing that one should use during a development process. Common Sense can be development by a process of constant learning and practice. I read the punchline on Peter's signature on this forum, work smarter not harder :) but I believe that you can only get smarter at first place by working hard, at least at the start of your career. Learning process improves your knowledge and your common sense will automatically 'click' as soon as you read/listen a good suggestion about architecture (and may be about everything in life).

The reason of my posting so many questions is that I know that by learning from all you people I can become smarter while developing software products.

Many thanks everyone.

Tahir

 
Old February 7th, 2007, 06:04 PM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I work with a design but constantly learning to improve that. How I reached to that design is simple. Consider that in a business application we have business objects like Customer, Employee, Product, Tax, Pension etc. Now in first draft lets say that object will have attributes(fields/properties) and behavior(methods) related to the business logic. Now if we have to store that object in a database then ofcourse that object will have data access logic as well. So far so good. This is a valid design may be not a good one. Why? An object is doing more than one thing i.e. breaking the important OO property of Cohesion. I then splitted the object into two, one that has fields and business logic, other will have data access. So far so good. This again is a valid design but may be not a good one. Why? Data Access object will need to fill the fields of this object somehow. There are few options now but by splitting the business into two objects, one that contains only values (Value Object design pattern) and one that contains business logic, we get a flexible design.

We then have three objects: Value Object, Business Logic Object, and Data Access Object. I mentioned in one of my previous post that the benifit I see in this design is that its more of a Service Oriented in nature. Considering that BL and DA objects will have behavior only (methods) these objects are providing services to the application. I agree that these are not loosely coupled, which is a requirement for a SOA however my common sense says that this is a SOA and not an OOA. Why? Because where are the objects in this design? BL and DA objects are not objects and neither is Value Object (fields only). Why are they not objects? Because for an object there must be properties and behavior in it. Object Oriented programming was inspired by our life i.e. real world objects. Not many real world objects will only have either properties or behavior. Usually objects in real world will have both.

These are my ideas and I am still learning...

Tahir

 
Old February 8th, 2007, 11:33 AM
planoie's Avatar
Friend of Wrox
 
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Tahir,
- What rule says that an object must have data AND behavior?
- I don't think that SOA and OOA have to be mutually exclusive. SOA most certainly can use objects so it is itself an OOA.
- My interpretation of SOA suggests that in order to be SOA the application components extend across application domains. I.e. different app domains that talk across web services, remoting, etc. I don't think that code that call methods on other objects can be considered SOA. That would mean that my one line program consisting of "Console.WriteLine('Hello World')" could be considered SOA because I call the "WriteLine" service of the Console class.
Quote:
quote:What do you think about my approach and what flaws do you see it in?
Your approach is mostly the same as mine. However, I'm not sure I understand what the BusinessProcesses layer adds. I would think that is what BLL is for, hence the name "business logic".

I am beginning to see more how Imar's and my ideas and approaches differ. Much of it comes from the different business demands we are each answering to. Imar works for a company that does more one-off type applications/websites. I have always worked for companies that do enterprise level applications. Thus, Imar can use simpler techniques without as much concern about them coming back to haunt him. I have to expect that my applications will start as mice and become elephants so I need to build for expansion. (Imar, please correct me if I've assumed incorrectly.)

-Peter
 
Old February 8th, 2007, 11:59 AM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

There is no rule that says object should have both attributes and behavior. I was just saying that usually an object in real-world will have both and because OOP is inspired by the real-world objects, I have this concept of object in my mind to keep things simpler.

I agree that the design you are working with and as you said I am working with are NOT strickly SOA. Concept of a service in my mind is an object providing some sort of service to its caller and that object does not have attributes. That is why I said that for me a SOA is one that has Services (class with methods only) because I dont consider them objects as objects for me are classes with both attributes and methods.

I know this sound a bit hmmm not right but thinking in this way makes me understand the business application I work on.

I agree with you (Peter) about projects growing in size. I have witnessed that in my short career. In these conditions it is important to keep a clean and flexible architecture. Company where I have worked (and working) are creating products rather than doing projects. This means that the architecture becomes even more important because we have think not only about architecture for one product but a line of products. Something that is known as Product Line Architecture.

One question: What naming conventios do you use i.e prefixes for classes and names of namespaces for various layers. One of the problem with our field is that we dont have many standards as we should have like other professions. I am asking to learn about this as well :)


 
Old February 8th, 2007, 12:43 PM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Peter,

By BusinesProcesses I mean a layer that orchestrates a process. A process will call one business object for something, then other business object for something else and then thid and so on. Usually for small projects UI is responsible for such things but I prefer to keep this in a seperate layer. It can indeed be part of BLL or it can be a seperate layer.

Tahir

 
Old February 8th, 2007, 05:56 PM
Authorized User
 
Join Date: Jan 2007
Posts: 54
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Imar,

Regarding the binding problem I had: I created NameValue object and it works fine when retrieving recrod. However, it does not work with Bind("") e.g. Bind("Client.Value"). Do you have any suggestions how to send the value back to data access object.

Tahir

 
Old February 9th, 2007, 11:13 AM
planoie's Avatar
Friend of Wrox
 
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Quote:
quote:Originally posted by tna55
 One question: What naming conventios do you use i.e prefixes for classes and names of namespaces for various layers. One of the problem with our field is that we dont have many standards as we should have like other professions. I am asking to learn about this as well :)

There are no standards across the programming profession. I'm sure this is because A) programmers are stuborn and want to do things their own way, and B) the industry doesn't need them.

Microsoft has a white paper in their patterns & practices area entitled Team Development with Visual Studio .NET and Visual SourceSafe published in 2002:

http://msdn2.microsoft.com/en-us/library/ms998239.aspx

I'm sure they have updated it since then so I'd be curious to see the latest version(s)/variation. The paper provides suggestions for working within a team, how to organize projects, namespaces and there might even be some convention suggestions.

Here's a collection of Microsoft's patterns & practices Guides:

http://msdn.microsoft.com/practices/...s/default.aspx
http://msdn2.microsoft.com/en-us/library/aa137892.aspx

I follow this namespace naming pattern:

<company>.<product>

I often append something indicating the application type as well. As far as class names go, name them for what they are. Because every object is a class in .Net, I see no reason to use any prefix for classes. Search for "conventions" on this forum and you might find some other posts with more details as I'm sure I've answered that question before.


Let's imagine I were building a bookstore website for Wrox (division of Wiley, something to keep in mind). It has its own support libraries and a windows service ("server" component) for backend processing. When building the server component, it's much easier to test it running as a console than as a service, so there are two applications to run the server. It also uses some enterprise level libraries at the Wiley level. I might end up with this list of project assemblies:

Support Libraries:
- Wiley.Enterprise.Purchasing.BO
- Wiley.Enterprise.Purchasing.DAL
- Wiley.Enterprise.Purchasing.BLL
- Wiley.Wrox.BookStore.BO
- Wiley.Wrox.BookStore.DAL
- Wiley.Wrox.BookStore.BLL
- Wiley.Wrox.BookStore.Util

Bookstore website:
- Wiley.Wrox.BookStore.Web

Backend server component:
- Wiley.Wrox.BookStore.Server (the guts of the server)
- Wiley.Wrox.BookStore.Server.Service (windows service that runs the server)
- Wiley.Wrox.BookStore.Server.Console (test console for server)
(The second two are really just application stubs that provide entrypoints to the main server class.)


If you want to look at an application that is built by minds that are very close to a god of software architecture, Martin Fowler of ThoughtWorks, it might be worth some time to look at CruiseControl.Net (http://ccnet.thoughtworks.com/). It's an open source continuous integration tool. You can download the complete source code. I have yet to find a better example of a .net application the includes so many aspects of .Net technologies and good software design.

Its highlights:
- Good design pattern implementation
- Multithreading
- Remoting
- A website
- A windows service
- A winform app (a task tray app at that!)


-Peter





Similar Threads
Thread Thread Starter Forum Replies Last Post
Binding ComboBox inside ListView problem gunnjamie Windows Presentation Foundation 1 July 17th, 2008 02:13 PM
Binding SQLDataSource To A Label Control sg225551 ASP.NET 2.0 Basics 1 January 16th, 2008 10:36 AM
TextBox inside GridView michurin ASP.NET 2.0 Basics 2 January 13th, 2007 12:51 PM
DropDownList inside a GridView aidoco ASP.NET 2.0 Basics 0 October 13th, 2006 04:24 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.