Design and Architecture

Pawel Krakowiak30-Oct-07 22:11

30-Oct-07 22:11

Mark Churchill wrote:
It seems to me you should be binding your datagrid to
Widget.WidgetId | Widget.WidgetName | Widget.Owner.LastName | Widget.Owner.Email

Yeah, I redesigned the application, so now my business objects make more sense.

I could write a SQL query (stored proc) which would return data from joined tables, then create another Table Adapter and BO. But this doesn't look good to me in terms of design. First rule is you should not update the business layer to meet the UI requirements, it should be exactly the opposite. And that's why I don't like the idea of creating a new BO just for displaying statistics in a GridView in the presentation layer.

My problem (at least a similar one) was already discussed at ASP.NET Forums[^].

Thanks.

Kind regards,
Pawel Krakowiak

led mike31-Oct-07 4:56

led mike

31-Oct-07 4:56

Pawel Krakowiak wrote:
First rule is you should not update the business layer to meet the UI requirements

I never heard that rule, can you provide a link to your source?

Pawel Krakowiak31-Oct-07 5:08

31-Oct-07 5:08

led mike wrote:
I never heard that rule, can you provide a link to your source?

It's called common sense. Wink | ;)

The whole idea behind decoupled modules is to make them pluggable, so you can throw out your ASP.NET UI and plug in WinForms and it will still work, because the business layer stays the same. If you start adding UI related stuff to your BOs you are coupling those two layers again. In the end when you want to switch the UI you have to rewrite the BOs or end up with BOs hanging in the air (not used anymore) and writing new ones.

I guess the size of your project is important and its particular requirements, right? Follow the ASP.NET Forums discussion if you want, I am just agreeing with some opinions there.

Kind regards,
Pawel Krakowiak

led mike31-Oct-07 5:36

led mike

31-Oct-07 5:36

Pawel Krakowiak wrote:
It's called common sense.

I see you are joking but seriously I have my own Number One Rule: Don't make stuff up.

What I mean by that is that so much information is available now there is no need to in 99.9% of the work I do.

Pawel Krakowiak wrote:
and its particular requirements, right?

Yes requirements, and analysis, are the key in your problem. What I mean is, if you have discovered a missing requirement or incomplete analysis then of course it might require a change in any layer(s) or part(s) of your system or even design dependencies forcing a refactoring to alter the design.

Pawel Krakowiak wrote:
but now I came to the point where I must display combined data in a GridView

Certainly that could have been anticipated but that is what iterative development is about. Understanding that we are not always able to have all the requirements before we start designing or that our analysis might be flawed or have holes. When these issues occur what we hope to find is that our design supports adding the new feature but even that is not always possible.

Pawel Krakowiak31-Oct-07 7:54

31-Oct-07 7:54

led mike wrote:
I see you are joking but seriously I have my own Number One Rule: Don't make stuff up.

I shouldn't have said 'rule', rather 'suggestion' or 'good practice'. Of course there are no rules which say you can't include UI stuff in your business layer.

led mike wrote:

Certainly that could have been anticipated but that is what iterative development is about.

In this particular project the statistics were to be supported by an external system, but we had to put the website in an IFrame (which wasn't planned) and the external system doesn't work that way, so I had to write my own statistics "engine" and now I need to include a couple of stats pages. But this doesn't mean I should be adding Business Objects which represent "a statistic", which really consists of a few fields taken from two objects which already exists - GUI should do the job - it already can get the objects and should take care of combining and displaying them. I was looking for somebody to tell me maybe that creating a new BO just for this purpose was OK, even though I didn't like it, hence my original question. Smile | :)

Anyway, as you originally said, this would be difficult without showing my classes. I asked a theoretical question.

Oh, by the way - regarding the 'accessors are evil' article - you must have public properties in order to bind ASP.NET controls to data. .NET Framework itself is full of properties, sometimes they are more readable in code and easier to use, but as someone (maybe it was in that article?) said - working for Sun or Microsoft doesn't magically improve your skills. Wink | ;)

Kind regards,
Pawel Krakowiak

Mark Churchill31-Oct-07 18:09

31-Oct-07 18:09

I don't totally agree here. Implementation aside, if you were to draw me an ERD then you would agree that Widgets have an Owner of type Person. A person owns none or more widgets. Regardless of whether you have a ASP.Net/Webforms or command line, this relationship exists.

You business layer should also have Widget.Owner, and likely Person.Widgets[]. Sure, your database reflects this as a foreign key. Thats fine. Call it a coincidence. Your BL is based off the ERD, your database is also based off the ERD.

They do both represent the same things, expect them to be similar.

Mark Churchill
Director
Dunn & Churchill

Pawel Krakowiak1-Nov-07 4:16

1-Nov-07 4:16

Mark Churchill wrote:
You business layer should also have Widget.Owner, and likely Person.Widgets[]. Sure, your database reflects this as a foreign key. Thats fine. Call it a coincidence. Your BL is based off the ERD, your database is also based off the ERD.

Mark, but this leads to a circular dependency, i.e. a Person has Widgets collection, each widget has an Owner, which is a Person, which has a Widgets collection, each widget has an Owner, which is a Person, which has a Widgets collection, each widget has an Owner...

You know what I mean? Smile | :)

Currently my idea is to have a User class, which contains WidgetList (inherits from List[Widget]), but Widget only has UserId as its owner, not the whole object. If you need the owner, you can retrieve it from UserManager (another class which manages objects of type User). This, of course, means that ASP.NET databinding is not so easy, because I need to add some TemplateFields and fill them in in GridView event handlers.

Kind regards,
Pawel Krakowiak

Mark Churchill1-Nov-07 16:20

1-Nov-07 16:20

That circular dependancy seems to be correct behaviour to me. What is important is that the User and the Widget are the same instance every time around.

I would expect "somePerson == somePerson.Widgets[0].Owner".

This is similar to say a heirachy of Controls on a page. "someThing.Controls[0].Parent" could have you going in circles in a similar manner.

Diamond Binding will give you a Owner property on the Widget class of type Person, and an IList<widget> on the Person class. The actual implementation of IList depends on whether you have picked lazy-loading. You could also configure an IDictionary<x,widget> where x is a property of Widget that is unique per Person.

Think of it this way: Is it incorrect of me to ask "Who is your father's son's father's son's father?". It might be inefficient of me to ask that, but the query has an answer in your problem domain.

Mark Churchill
Director
Dunn & Churchill

Pawel Krakowiak1-Nov-07 23:41

1-Nov-07 23:41

So, you suggest to have an accessor like this:

<code>private int _ownerId; // This is initialized elsewhere.

public User Owner
{
   get
   {
      // Lazy loads the User object upon request by using the UserManager class'
      // static method.
      return UserManager.GetUserById(_ownerId);
   }
   set
   {
      // Cast value to User object and retrieve it's ID.
      _ownerId = ((User)value).UserId;
   }
}</code>

User = Person, I currently have that class named User, although it conflicts with a class from .NET Framework sometimes, so renaming it to Person is a good idea.

This is a simplified example, but something like the above? This would allow to bind easily the property in ASP.NET, like "User.Owner.FullName", but still wouldn't endlessly load objects, right?

BTW. Is DiamondBinding an ORM? I have currently a license for EntitySpaces[^], but am not using it at the moment. The way how ORMs present the objects looks like more fitting for the DAL rather than BLL... But this is an another discussion. Wink | ;)

Kind regards,
Pawel Krakowiak

Mark Churchill2-Nov-07 1:50

2-Nov-07 1:50

Yep that seems ok. If the UserManager has a caching strategy of some sort then you won't have any problems with circular references giving you duplicate objects either. (Although theres a redundant cast in that setter Wink | ;)

).

You could also keep a local cache of the child object - this would be more efficient when pulling out say User.Owner.FirstName + User.Owner.LastName - it would avoid two trips to the UserManager. Of course with any caching you have stale-cache issues to solve Wink | ;)

As for lists, you can have your Widget collection implement IList<widget>, but not actually retrieving the objects until iterated or an item requested (lazy loading again).

Diamond Binding is an ORM and definition generator. It follows the ActiveRecord model, so its less data-model oriented than other ORMs - so you are mainly dealing with objects at a business level: Customer c = Customer.Find(primaryKey); IList/Customer/ l = Customer.FindAll(); (Edit: Forum broke my generics!) Theres an example on the product page here[^]. Give the Personal Edition a try if you like, theres no functional difference between it and the Professional / Enterprise Editions. We aim to handle the entire data access requirements and just let you build business logic on top of the model we give you.

Mark Churchill
Director
Dunn & Churchill

Pawel Krakowiak2-Nov-07 2:01

2-Nov-07 2:01

Mark Churchill wrote:
If the UserManager has a caching strategy of some sort then you won't have any problems with circular references giving you duplicate objects either.

I am not sure how to do this yet, can you point me to some articles?

Mark Churchill wrote:
Although theres a redundant cast in that setter

Yes. I thought value was of type object, forum doesn't give me any guidelines. Poke tongue | ;-P

Thanks for all your comments so far.

Kind regards,
Pawel Krakowiak

Mark Churchill2-Nov-07 2:57

2-Nov-07 2:57

A really simplistic implementation would be to add the caching to your UserManager.Load(object pk). Check the cache, and if its in the cache then return it. Otherwise load the object's data and add it to the cache.

You can use a Dictionary for your cache for prototyping. ASP.Net provides a cache (I think you can safely use this outside of the web framework too) that you can add objects to with a key and an expiry.

You might want to add some way of forcing a reload of an object as well. To be honest though if you are writing your own data layer you are going to have to draw the line for features somewhere. I haven't done a KLOC count on Diamond Binding for a while - but I'm guessing its approaching the millions, and thats not including NHibernate Wink | ;)

Mark Churchill
Director
Dunn & Churchill

martin_hughes2-Nov-07 7:44

martin_hughes

2-Nov-07 7:44

Slightly OT... But I was wondering, how does Diamon Binding differ/compare to the ADO.Net Entity Framework coming up in VS2008?

Me: Can you see the "up" arrow?
User:Errr...ummm....no.
Me: Can you see an arrow that points upwards?
User: Oh yes, I see it now!

-Excerpt from a support call taken by me, 08/31/2007

Mark Churchill2-Nov-07 16:39

2-Nov-07 16:39

I guess the cheeky reply is that Diamond Binding is avaliable now, and is mature, and leveraging Hibernate, which is also decades mature. Last I heard the Entity Framework was dropped from Orcas and was going to be released "out-of-band" sometime in the first half of 2008.

EF, like a lot of ORM products tends to be very heavyweight and favours model-first development. It is a very complex product, however I think the key feature that everyone is interested in is LINQ to Entities. LINQ is not really EF specific. After the product becomes more mature, we will look at including LINQ support in Diamond Binding. Although we find that Expressions and HQL support cover most use cases sufficiently at the moment.

DB is designed with simplicity in mind, and is geared towards keeping your business objects synchronised with the database schema, and handling everything in between for you. If the schema changes, its a one-click synchronisation. One aim is to stop developers getting bogged down in mapping, and just let them add business value to the application!

Mark Churchill
Director
Dunn & Churchill

Pawel Krakowiak2-Nov-07 10:55

2-Nov-07 10:55

Mark Churchill wrote:
A really simplistic implementation would be to add the caching to your UserManager.Load(object pk). Check the cache, and if its in the cache then return it. Otherwise load the object's data and add it to the cache.

Sure, but I am concerned with the stateless behavior of web application / HTTP. As far as I know when the page is pushed back to the calling browser, it is disposed of and doesn't exist anymore, hence I am not sure how to cache data, otherwise than in some process which runs all the time on the server. Honestly, I haven't been playing with cache mechanisms of .NET yet, it's something on my list.

Kind regards,
Pawel Krakowiak

Mark Churchill2-Nov-07 16:24