View layer implementation

[Arne Vajhøj]

Show some facts...

Get some glasses and read the next lines.

Show some facts other than your lip-service.

That same problem and "I disagree here too" does not match
is just a matter of basic English.

Arne

 

[Arne Vajhøj]

Show some facts........

Get glasses and read what I wrote. The reasons were given 2 lines
above.

Arne

 

[Arne Vajhøj]

On 1/10/2011 8:14 PM, Arne Vajhøj wrote:
On 10-01-2011 13:18, mp 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.

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

I can call it a reference. I am not into the nit picking like you are
into it.

You could also decide to class a class for a method and a method
for a class.

But that will just confuse people.

It is extremely important with a common terminology in software
development to avoid misunderstandings.

And I consider it very bad of you to try and misguide people
wanting to learn C# and .NET the wrong terminology.

Arne

 

[Arne Vajhøj]

<snipped I stopped reading your posts you are too overbearing>

<yawn>

See ya I wouldn't want to be ya.

I am afraid that this type of reaction stopped impressing
people around 3rd grade.

Arne

 

[Arne Vajhøj]

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.

And I forgot the .NET specific advantage of enabling additional
encapsulation via the internal accessibility.

Arne

 

[Arne Vajhøj]

On 1/11/2011 9:12 PM, Arne Vajhøj wrote:

<snipped I didn't read it>

You don't think it looks a little bit dumb to reply
to something without reading??

Arne

 

[Arne Vajhøj]

On 09-01-2011 01:32, Big Steel wrote:
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.

I don't see any facts.

Try read the original MVP paper from 1996.

Arne

 

[Arne Vajhøj]

It is not and was not.



It seem clear to me and the others working on the project.



Who says the BLL and DAL have to be in different projects? Show where
this is written in stone.

It is not written in stone.

But part of good software architecture.

The whole purpose of layers is to decouple.

Different assemblies/project enables you to decouple
more.

The BLL would have it's method that created the DAL object and a mapped
class can be used too, which is much simpler if the BLL and DAL are in
the same project.

simpler != better

Either the lower layer should expose a factory class, some
interfaces and some data classes only to the upper layer.

Or it should go one step further and use a DI framework for
wiring them together.

They key is decoupling - not being easy to refer forth and back.

If it's not broke don't fix it.

Not decoupling ones layers is seriously broken.

There are many ways one can do things,
and as far as I am concerned, no one way is the right way.

There are cases where there are more than one viable solution.

But there are certainly also cases where there only one good
solution.

You are talking about dependencies and whatnot. It's all inner-dependent
no matter how one looks at it.

No.

Good software architecture minimizes the number of dependencies.

And it is doable.

Arne

 

[Arne Vajhøj]

<snipped I didn't read it>

You should have - you would have learned something.

Why don't you take a chill-pill and try settling down?

I just don't want to see a bunch of new .NET developers
coming out with poor understanding of layering and very
difficult to understand because they use another
terminology than the rest of the .NET world.

Arne