I am by no means a pro at Object Oriented Architecture, and so I'm requesting if anyone can point me in thr right direction. I love the idea of O/R Mappers, automatic code generation tools and the like, but before delving into these, i really want to be able
to code my layers manually, and design them well. There are so many different ways of producing the same result, but in object oriented terms there seems to only be a few ways to do it properly, and this is what I'm looking for. I have read loads of books
and viewed the source code of many sample apps but still I seem to be without a solid answer as to how i should design my objects. The Microsoft Pet Shop has the UI code behind call the business layer that then calls the data access layer which queries the
database and puts the values into the model objects that it creates and sends them back to the UI via the business objects. Is this what is known as the MVC(Model View Controller). It seems wrong to me because surely the UI needs a reference to the Model objects
as well as the Data Access Layer. Is this a good way to do your layers or a bad way? I know that asking 'which is the best way to design your layers' is a bit of a broad question because it is all down to the project that I'm doing, but there must be a way
to set the layers out that gets used in a normal situation. Should you have a BLL and another layer which represents the actual objects you are modelling, or should the BLL be the actual objects that you are modelling. You can probably tell how confused I
am by the state of the layout of my question here. Please help! And Many Thanks
You're exactly right. It's been said here several times that MS examples are often not best practices for the OO world. Much of the OO knowledge I have was gained by reading books (Craig Larman's is EXCELLENT) and trial and error. I suggest taking a domain
problem that you really understand well and going through the process of developing an OO application for it. I know it takes a lot of time but it is really good experience. You're going to make mistakes but as long as you're learning from them then you'll
be a lot better off. As far as MVC, I don't really know what to say. I struggled with it ALOT when I first started learning/using it. Since then I've written several apps that use it and have a much better grasp of it. It is definitely not a silver bullet,
but I like the abstractions that it provides. As of now I have a framework I've developed for applications to use MVC. I'm pretty comfortable with its features, but it is still more work than "putting code behind the buttons". I have roughly 5 "tiers" in my
windows applications. 1) The Form (view) itself. 2) The controller for the Form. 3) Business objects. 4) Application specific DAL. 5) Generic DAL. In my windows apps I have the following basic responsibilities: Windows Forms (Views): Fire events from the user
and display data to the user. Controllers: Listen for events fired from the Windows forms, maps UI fields into the business objects and business object data into UI fields, call application DAL w/ business objects (to load/save/delete, etc). Business Objects
(Model): Model the domain problem. Business Object Data Layer (App specific): Generate and execute commands to save/load/delete business objects. Generic Data Layer: Execute the commands generated by Business Object Data Layer using ADO.NET data access objects.
I'm not saying this is the best architecture, but it has worked pretty well for us so far. I would eventually like to explore more databinding, but for now we write our own binding routines. As time has passed we've abstracted more and more of the reusable
code into a set of "base" objects. Initially we also developed our own data layers. However, now we mostly use an O/R Mapper and abstract it's calls using a facade class. This way we make our application as seperated as possible from the O/R Mapper specific
code. Smoke
Thona, Was hoping you would get involved. MVC was an architecture in VB6 days, is that correct? In Petshop 3.0, i think it's version 3, Microsoft have a UI Layer, BLL Layer, DAL layer and also a Model layer, i know that the code is rrrrrrrubbish, but is this
architecture right? As far as my knowledge goes, this isn't good, because they seem to have all layers connected some how, i thought the idea was that the UI had knowledge of BLL only, BLL has knowledge of DAL only, although none are reliant on the other.
Is this correct? I thought that the BLL was the business entity being modeled, but in Petshop, the BLL seems to control the business rules while the Model is the entity. Thona any chance you could give me your experienced opinion? Thankyou
I'm very interested in hearing an expounding upon "No and No", also. I've had my fair share of questions regarding the coupling between layers and where it should exist. Hopefully this will shed some light on what others are doing in regard to this. Smoke
::MVC was an architecture in VB6 days, is that correct? No. It is still around. ::In Petshop 3.0, i think it's version 3, Microsoft have a UI Layer, BLL Layer, DAL layer and ::also a Model layer, i know that the code is rrrrrrrubbish, but is this architecture
right It is an architecture I would personally fire anyone involved for. The DAL layer they have is among the worst possible solutions - copy paste code like hell. It is BERARABLE if you use a CodeGen (which they do not), but it is no replacement for a real
powerfull DAL like every O/R mapper has. ::As far as my knowledge goes, this isn't good, because they seem to have all layers ::connected some how, i thought the idea was that the UI had knowledge of BLL only, BLL ::has knowledge of DAL only, although none
are reliant on the other. Is this correct? Yes, with the one exception that naturally the DAL needs to know the layout of the objects of the BLL. Note that this does not mean structures etc - Knowledge means, for example, that the BLL hands down a configuration
file. ::I thought that the BLL was the business entity being modeled, but in Petshop, the BLL ::seems to control the business rules while the Model is the entity. MS does not has not and propably will never understand what a Domain Model is good for. They
go for a service oriented model - which I personally see a lot of problems in, mostly in the "reuse" section. Change the UI and you end up writing a significant amount of additional code. Personally I think PetShop 3 is about the worst possible example of
an architecture. Others are the asp.net forums (heavily relying on stored procedures which I think is a negative thing - forums are not in the need for them), IBuySpy (never being an architecture sample in the first placew, though people try to make it one).
::Thona any chance you could give me your experienced opinion? Outside here? My rate is 150 EUR an hour :-)
I used to worry about tiers too. Basically, I gave up because I don't see the point. Once you have a good Domain Model, where your BBL/Objects are one-in-the-same, and Persistence is used in either the Domain or Presentation layers freely, then it's easy, so
I just don't worry. In other words:
// User.cs
public class User()
{
// members go here...
public static User Login(string userName, string password)
{
User user = null;
// Get user from database, log stuff, check and update attempted logins count, etc etc...
return user;
}
}
// MyPage.aspx.cs
private void Login_OnClick(object sender, EventArgs e)
{
Entity.User user = Entity.User.Login(TextBox1.Text, TextBox2.Text);
if(user != null)
{
Session["UserId"] = user.Id;
Response.Redirect("~/somepage.aspx");
}
else
TextBox3.Text = "No dice.";
}
A more specific question that I have is - who is responsible for invoking the DAL operations? Several options I see are: 1. BLL has methods to call the DAL and perform DB operations (ex. User.Load(id), User.Save(), etc). This results in the UI/Controllers calling
User.Save(), etc and not knowing anything about the DAL. 2. UI/Controllers know about the DAL and call its methods (ex. UI calls PersistentStore.Save(User) or User = PersistentStore.Load(typeof(User), id). This results in the BLL not knowing anything about
the DAL, but the UI knows about both BLL and DAL. Personally, I favor option #2 right now. This is because I favor a "cleaner" BLL that doesn't necessarily care if it is persisted or not. I view the UI layer as the area of the code that knows if an object
should be persisted and who to give the object to to accomplish the save. I can see this leading to some duplicate code though, if you have an application that has both a Windows and Web GUI. Perhaps this is a "pick your poison" type of argument. I'm just
curious as to how others are handling this coupling. Smoke
trev.pope
Member
25 Points
5 Posts
Best Architecture
Oct 12, 2004 11:51 AM|LINK
mynameismud
Participant
1210 Points
242 Posts
Re: Best Architecture
Oct 12, 2004 12:25 PM|LINK
trev.pope
Member
25 Points
5 Posts
Re: Best Architecture
Oct 12, 2004 12:47 PM|LINK
rsmoke21
Contributor
3931 Points
792 Posts
Re: Best Architecture
Oct 12, 2004 01:44 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Best Architecture
Oct 12, 2004 01:45 PM|LINK
trev.pope
Member
25 Points
5 Posts
Re: Best Architecture
Oct 12, 2004 02:19 PM|LINK
rsmoke21
Contributor
3931 Points
792 Posts
Re: Best Architecture
Oct 12, 2004 03:57 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Best Architecture
Oct 12, 2004 06:41 PM|LINK
ssmoot
Participant
1760 Points
352 Posts
Re: Best Architecture
Oct 12, 2004 07:49 PM|LINK
// User.cs public class User() { // members go here... public static User Login(string userName, string password) { User user = null; // Get user from database, log stuff, check and update attempted logins count, etc etc... return user; } } // MyPage.aspx.cs private void Login_OnClick(object sender, EventArgs e) { Entity.User user = Entity.User.Login(TextBox1.Text, TextBox2.Text); if(user != null) { Session["UserId"] = user.Id; Response.Redirect("~/somepage.aspx"); } else TextBox3.Text = "No dice."; }But maybe that's just me...rsmoke21
Contributor
3931 Points
792 Posts
Re: Best Architecture
Oct 12, 2004 09:22 PM|LINK