View layer implementation

M

mp

another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be doing with
that...at least in this example)
i've put this togeter from examples so only half understand what i've
done...<g>
one thing i wonder about...
the presentation layer is defining an interface the view layer is deriving
from...is that the right 'layout / heirarchy'?
namespace Investments.ViewLayer
{
//IInvestmentListView interface defined in Investments.PresentationLayer
public partial class InvestmentsView : Form, IInvestmentListView
{....}
}

....also....
is the following the right place for the view to implement displaying some
information?

//a button in the view raises an event
private void btnLoadPortfolio_Click(object sender, EventArgs e)
{
if (this.LoadPortfolio != null)
{
this.LoadPortfolio(this, EventArgs.Empty);
}
}

//an object in the presenter catches the event and creates a bus.obj. to
service request
private void mView_LoadPortfolio(object sender, EventArgs e)
{
MessageBox.Show("catch event in Investment list presentation
layer");
try
{
Investments.BusinessLayer.Portfolio p = new
Investments.BusinessLayer.Portfolio();

//send data back to view to display
this.mView.StockWatchDataSource = p.StocksToWatch; //<<<<<
gets list of stock tickers from excel spreadsheet
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
throw;
}
}

//back in the view.cs
//for the view to display the info, is the *set* of the property the
"correct" place to put the implementation?
public StockListCollection StockWatchDataSource
{
set
{
//get List<string> passed into this property from presenter
StockListCollection internalCol = value;

//display list of tickers in gridview
this.grdInvestments.Columns.Add("ID", "ID");
this.grdInvestments.Columns.Add("Ticker", "Ticker");
for (int i = 0; i < internalCol.Count; i++)
{
DataGridViewRow item = new DataGridViewRow();
item.CreateCells(this.grdInvestments);
item.Cells[0].Value = i;
item.Cells[1].Value = internalCol;
this.grdInvestments.Rows.Add(item);
}
}
}

thanks
mark
 
A

Arne Vajhøj

another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be doing with
that...at least in this example)
i've put this togeter from examples so only half understand what i've
done...<g>
one thing i wonder about...
the presentation layer is defining an interface the view layer is deriving
from...is that the right 'layout / heirarchy'?

All of M, V and P are part of presentation layer.

[code snippets deleted]

I can not comment on the specific code.

Arne
 
A

Arne Vajhøj

Arne Vajhøj said:
another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be doing
with
that...at least in this example)
i've put this togeter from examples so only half understand what i've
done...<g>
one thing i wonder about...
the presentation layer is defining an interface the view layer is
deriving
from...is that the right 'layout / heirarchy'?

All of M, V and P are part of presentation layer.

[code snippets deleted]

I can not comment on the specific code.
oh, i've misunderstood something then
i thought they were 3 different layers...they are 3 different projects....

Not 3 different layers. And I would say not in 3 different projects
either.

Different classes and source files. Possibly different namespaces
(lowest level). But not different projects.

Arne
 
M

mp

Big Steel said:
another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be doing with
that...at least in this example)

The service layer [...]>
If this is a Windows desktop solution and it is not a multi user
application, then you don't need the service layer. You can have the BLL
directly call the DAL.

ok in my current project I don't need the service layer...I have just been
trying to 'copy' the mvp project layout you linked me to recently (obviously
i don't understand what i'm doing)...the other responders have pointed out I
shouldn't have separate projects and that all these 3 pieces are in one
layer...the sample project had 4 projects and called them different
layers(iirc)

[...]
The Interface should be for the entire form.

but is it correct that the interface is defined in the presenter?

All the controls on the
form are represented in the IView.

are the controls represented as properties?

[...]
//a button in the view raises an event
private void btnLoadPortfolio_Click(object sender, EventArgs e)
[...]

It seems ok from what I can see.
[...]


The get/set should be in the IView for the control.

sorry i'm not understanding....
if i have a form with a button and a datagridview
what would that code look like?

The get/set for the control would be in the Interface of the form.

At the UI form in its Interface, the get/set will point to a control on
the form. If mpListview in the name of a control on the form, the get
(mpListview) and the set (mpListview) = value will be used. The
impListview is getting and sitting the control mpListview on the form.

In the presenter.......

var ctrl = mview.impListview ..... the get

mview.impListview.Datasource = p ... the set



mpListview is an object,

meaning the presenter doesn't know *what kind of* object?
only the form knows it's own actual controls, right?
so lets say i have 3 different forms
one displays in a textbox, one displays in a listview, and one displays in a
DataGridView
they could each implement the same interface
and the interface would have a definition for, lets say, "DisplayObject"
and the presenter won't know or care what kind of display object it's
talking to...just that there's an interface and properties it sets
??? am I totally off track here...i'm feeling very lost after the last batch
of responses I've gotten...

thanks for hanging in with my beginner ignorance
Mark
 
M

mp

Peter Duniho said:
[...]
the presentation layer is defining an interface the view layer is
deriving
from...is that the right 'layout / heirarchy'?
[...]


Seems fine to me. Though, in general I would say that a design that
requires the instantiation of an object just to get some property value
from that object suggests that the property belongs elsewhere, either as
an instance member of a type that will already be instantiated or perhaps
as a static member somewhere.

i'm assuming that the object will do more in the future,,,
just trying to see if i'm understanding the structure of these different
'players'
and how they're talking to each other to provide proper decoupling
as i'm just beginning to look at implementing this little new tool

[...]
I think a property setter is fine for some things. But a common rule of
thumb is to avoid write-only properties, which you appear to have here.

yeah, i don't know why it's that way...just following an other example i was
led to by other links recently

[...]
Unless the data source you're setting here is something that makes sense
to be able to retrieve later, it probably makes more sense for you to set
it using a method instead.

Pete


Thanks for your responses...it will take me a while to digest this all
the more i try to learn the less i feel like i understand
:)
mark
 
M

mp

Steel said:
[...]

I wouldn't stray too far from what the tutorial is showing you, until you
understand what is happening.

The control is an object on the form. No matter where you are using the
control/object in the MVP between the UI and the Presenter, there is only
one instance of it. So if you do something in the Presenter with the
control/object, you are working with the control/object on the form, a
single copy/instance of the object.

thanks for your patient clarifications and explanations
Will try to digest all that...
Many Thanks
Mark
 
M

mp

Steel said:
[...]>
If this is a Windows desktop solution and it is not a multi user
application, then you don't need the service layer. You can have the BLL
directly call the DAL.

so i factored out the service layer
I would base everything you do based on what the tutorial project is
showing you, so that you understand logical tier separation (separate
project in a layer).

UI layer
Presenter layer
BLL layer
DAL layer

[...]

You should understand the service layer, which would be setting between
the BLL and the DAL. The BLL would be calling methods on the DAL through
the Interface that sits between the BLL and the DAL. The tutorial showed
you how the service layer interface is being used, which the service layer
could be working with a Web service too as an example. The service layer
is interchangeable.

maybe, since i deleted that level, i shouldn't try to understand the above
paragraph, but i would still like to get it...
in the example i'm looking at, the service object looks like it's sitting
between the presenter and the business object?

//in the 'presenter layer'
private ProductCollection AllProducts
{ get { ...
this.mAllProducts = this.mProductService.GetAllProducts();
<<<<< presenter delegates to service layer, right???

//in the ProductService.cs
public ProductCollection GetAllProducts()
{ ProductCollection products;
products = new ProductCollection(); <<<<<<service creates
business object, right???

maybe i'm just not understanding what you mean by BLL and DAL
I think they mean business logic and data access, right?

in my simple app the business layer is wanting to deal with certain
"investment" objects

the data access is just (at this point) reading some excel files where i
have some data stored
(list of stocks to watch)
(and soon to implement, going onto website to read stock data)(for each
stock,GetData)

i have both those processes implemented in my business.layer project
(whether that is right or not i don't know)
Investment.cs
Portfolio.cs
ExcelReader.cs
and i should move the webData reading into it's own object too i suppose
WebDataReader.cs

???does any of that make sense as a division of responsibility?
Thanks for helping my antique brain try to understand all this
mark
 
M

mp

Steel said:
Steel said:
On 1/8/2011 8:11 PM, mp wrote:
[...]>

That's the proper way to do it, but you can have the service layer sit
between the BLL and DAL too. It depends on how you want to do it.
//in the 'presenter layer'
private ProductCollection AllProducts
{ get { ...
this.mAllProducts = this.mProductService.GetAllProducts();
<<<<< presenter delegates to service layer, right???

Where are you getting this 'get'? There should be no get in this case.

it's from the tutorial #4...i just deleted a few extraneous(to this
question) lines
//http://www.polymorphicpodcast.com/

the full text is as follows:

private ProductCollection AllProducts
{
get
{
if (this.mAllProducts == null)
{
this.mAllProducts =
this.mProductService.GetAllProducts();
}
return this.mAllProducts;
}
}

Put it back the other way and use the service that sits between the UI and
the BLL.

i haven't moved anything...that's just from the tutorial
i just added the comment lines to clarify my understanding of what the
actors are doing here

again, full text from tutorial:
public ProductCollection GetAllProducts()
{
ProductCollection products;
Product product;

//fake getting all products
products = new ProductCollection();

for (int i = 0; i < 25; i++)
{
product = new Product();
product.ID = i;
product.Description = "Product " + i.ToString();
products.Add(product);
}

return products;
}

The service layer calls the method on the BLL to calling GetAllProducts().

The IService implements the interface to the method in the BLL.

public Interface IService
{
using BLL; // use the using statement pointing to the BLL if the
Productcollection class in in the BLL (business logic layer)

ProductCollection GetAllProducts() // this is interface that will
be implemeted in the BLL when the BLL has the IService implemented in the
BLL, just like it happened in the UI and IView but there is no get/set.
The interface in the BLL for the IService is just place holder methods in
the BLL.

}

public ProductCollection GetAllProducts()
{

return new BLL.GetAllProducts();
}


var products = mservice.GetAllProducts(); // just keeping it a simple
example here.


or

mview.Listview1.Datasource = mservice.GetAllProducts()



Yes you can do that.



You can have the BLL and DAL as folders in one classlib project using
folder reference call it myLib or something. You do this so that the BLL
and DAL can see the Investment.cs and the Protfolio.cs. The DAL is the one
that has the methods that creates the those objects, populates them and
returns them the the BLL. The DAL would have method called
GetAllProducts() to be consistent with the naming convention throughout
all the layers, leaving no doubt between layers as to what the
functionality is about 'GetAllProducts'.


This Web service call, you can worry about later. You should get the other
parts I have explained set first. You should go back and see how the
service layer is implemented in the tutorial between the Presenter and the
BLL.

i'll continue studying
thanks again
mark
 
M

mp

message [...]
You can have the BLL and DAL as folders in one classlib project using
folder reference call it myLib or something.

sorry you lost me there.
currently I have a folder for my businessLayer classlib project
....\DotNet\Projects\Investments\Investments.BusinessLayer
in that folder are cs files that make up the project
those listed above and a few others and the .csproj file etc.

I think my business objects are Investment.cs, Portfolio.cs
I think the DAL objects would be ExcelReader.cs and WebDataReader.cs
are you saying my files ExcelReader.cs and WebDataReader.cs should be in a
separate subfolder in the businessLayer folder?
....\DotNet\Projects\Investments\Investments.BusinessLayer\DAL

and I don't understand what you mean by refernceing a folder...i only see
the ability to reference files...
are you talking about the references node under the project node in the
solution explorer? AddReference?
 
M

mp

Big Steel said:
"Steel" <""Fake99XX1199999fake\"@(Big)(Steel)theXfactor.com"> wrote
[]
Yes and the other folder should be the BLL folder, with the
respective classes moved to those folders.

does the .csproj file stay in the root folder of the project?

[]

No, you see the reference to a folder above if you want to reference a
folder in a project that contains classes.

i cant' find how to reference a folder, I only see how to reference a
file???
The BLL object is returned back to the Manager. The Manager returns
the BLL object back through the service layer to the the Presenter.

I thought "we" got rid of the service layer due to this being a "simple"
app?
:)
are we bringing it back in?
 
A

Arne Vajhøj

Yes and the other folder should be the BLL folder, with the respective
classes moved to those folders.

There is another class that is missing called the Manager.cs that sits
in the root of the classlib project file. The Manager class is going to
implement IService, which is going to make stubs in the Manager.cs based
on the IService interface. It is also a using statement at the top of
the class the ie going to use folder reference for BLL and DAL folders
so that it can access the classes in the folders

using System;
using BLL;
using DAL;

Different layers should be in different projects.

Building multiple layers into same assembly is not good.

And if the intention is for some software to evolve, then
better namespace names should be used.

Arne
 
A

Arne Vajhøj

Big Steel said:
"Steel"<""Fake99XX1199999fake\"@(Big)(Steel)theXfactor.com"> wrote
[]
Yes and the other folder should be the BLL folder, with the
respective classes moved to those folders.

does the .csproj file stay in the root folder of the project?

It has to for the project to work.
i cant' find how to reference a folder, I only see how to reference a
file???

You don't need to add any reference.

When you add the file, the VS adds it to the project.

Folder or no folder.

Arne
 
A

Arne Vajhøj

Big Steel said:
another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be
doing with
that...at least in this example)

The service layer [...]>
If this is a Windows desktop solution and it is not a multi user
application, then you don't need the service layer. You can have the BLL
directly call the DAL.

ok in my current project I don't need the service layer...I have just
been
trying to 'copy' the mvp project layout you linked me to recently
(obviously
i don't understand what i'm doing)...the other responders have pointed
out I
shouldn't have separate projects and that all these 3 pieces are in one
layer...the sample project had 4 projects and called them different
layers(iirc)

I would base everything you do based on what the tutorial project is
showing you, so that you understand logical tier separation (separate
project in a layer).

UI layer
Presenter layer
BLL layer
DAL layer

I would consider it very unusual to have both a UI and
a presenter layer.

Arne
 
A

Arne Vajhøj

You can have the BLL and DAL as folders in one classlib project using
folder reference call it myLib or something. You do this so that the BLL
and DAL can see the Investment.cs and the Protfolio.cs.

That sounds pretty messy.

Nasty inter dependencies.

Much clearer with separate BLL and separate DAL project.

App depends on BLL only and BLL depends on DAL only.

Or create a DML and: app depends on BLL and DML, BLL
depends on DAL and DML and DAL depends on DML.

But only one way dependencies (high level depends
on lower level).
The DAL is the
one that has the methods that creates the those objects, populates them
and returns them the the BLL. The DAL would have method called
GetAllProducts() to be consistent with the naming convention throughout
all the layers, leaving no doubt between layers as to what the
functionality is about 'GetAllProducts'.

A BLL GetAllProducts() that just dispatches to DAL GetAllProducts()
can be an indication of a BLL that does not provide value but
is just a passthrough.

Arne
 
A

Arne Vajhøj

On 1/8/2011 8:11 PM, mp wrote:
another silly newbie question(s):
So I have a view/presenter/business layers setup
(i have a service layer too, but not sure what i'm supposed to be
doing with
that...at least in this example)

The service layer
[...]>
If this is a Windows desktop solution and it is not a multi user
application, then you don't need the service layer. You can have the BLL
directly call the DAL.

ok in my current project I don't need the service layer...I have just
been
trying to 'copy' the mvp project layout you linked me to recently
(obviously
i don't understand what i'm doing)...the other responders have pointed
out I
shouldn't have separate projects and that all these 3 pieces are in one
layer...the sample project had 4 projects and called them different
layers(iirc)

I would base everything you do based on what the tutorial project is
showing you, so that you understand logical tier separation (separate
project in a layer).

UI layer
Presenter layer
BLL layer
DAL layer

I would consider it very unusual to have both a UI and
a presenter layer.

Why even have that? I have seen it where the UI and Presenter are in the
same project --- no harm, no foul and cut down on the total number of
projects in a multi UI projects solution. :) It all sounds nice, and
then there is the real world.

In most of the real world they would be in one layer and in one
project.

For good reasons.

Arne
 
A

Arne Vajhøj

[]
Yes and the other folder should be the BLL folder, with the
respective classes moved to those folders.

does the .csproj file stay in the root folder of the project?

It has to for the project to work.
No, you see the reference to a folder above if you want to reference a
folder in a project that contains classes.

i cant' find how to reference a folder, I only see how to reference a
file???

You don't need to add any reference.

When you add the file, the VS adds it to the project.

Folder or no folder.

I say that you do.

using BLL = project.BLL; // the folder where all bussiness logic is kept.

using DAL = project.DAL; // folder where all data access classes are kept.

var inv = new DAL.Inventory();

var inventory = inv.GetInvByCustomerID(100);

I am not going to go by what you are saying, because I know better than
this as to what can be done and what cannot be done, when developing
enterprise level solutions.

But apparently you don't know that:
1) using aliases has nothing to do with references to folder
2) there are no concept of references to folders in .NET at all

Arne
 
A

Arne Vajhøj

I disagree with this, and it was shown to me as to the purpose of it,
which was to allow scalability and allowing the solution to evolve,
without needing a trillion projects to accomplish it.

Namespaces are completely irrelevant for assembly/project split.

But having 50 projects using the same namespaces is effectively
preventing any type of mix/reuse later.

Very bad.

Namespaces should follow a logical naming convention.

That is also Microsoft's recommendation:

http://msdn.microsoft.com/en-us/library/ms229026.aspx

(I can see a certain point instead of company name
to do it the Java way and use company domain, but that
is a detail)

Arne
 
A

Arne Vajhøj

No it doesn't. That's the traditional way of thinking. If the BLL and
DAL are dedicated to a particular business and data access
functionality, then they can be kept in one classlib project.

You have 50 projects that comprise an enterprise level application using
the same solution or sln. Each one of the projects has a specific
business functionality or business need, and each one of the project has
a BLL and DAL projects that it uses in the N-Tier solution. You are
talking 100 additional projects that are needed if each BLL and DAL are
separated into different projects used by the 50 projects.

If you have one classlib project that contains the BLL and DAL, then
only 50 projects are needed cutting down on the number of projects. So
there would only be the need for 100 projects total in the solution
instead of the 150 projects going by your scenario.

But if a project contains functionality that should be
separate then it is an advantage to split it.

* It can be reused by other higher level projects
* It is easier to different teams working on the different projects
* test and deployment of updates is cheaper due to reduced scope
etc.
I disagree here too.

Since it is the same discussion, then "too" does not make
any sense.

Arne
 
A

Arne Vajhøj

I am going to give you another example.

Service layer
WCF service
BLL and Model

The Model contains entities and the entities take care of themselves
with CRUD operations against SQL Server and DB2 databases with DB2
databases on an AS400.

There is no DAL. It's ADO.NET Entity Framework like, but there is no
ADO.NET EF involved. The company is developing its own EF like model.

Another situation I have worked in is there was no DAL and the BLL
objects did their own CRUD operations, kept their state and the whole
nine yards -- no DAL.

So it all depends on what one has seen and what someone knows.

And I'll say it again, no one way is the right way hammered into stone.

The fact that you may not need a DAL, but just a DML and .NET Framework
has really nothing to do with the need to separate layers.

Instead of Foobar.BLL.dll+Foobar.DAL.dll you will just have
Foobar.BLL.dll+Foobar.DML.dll.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top