N-Tier Design Question?

[Leon]

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic designers
but we are locally accessible. I want the application to be easy to
maintenance as well as extend. Plus I think if I use a .vb that contain all
of "let say" user interaction information ("such as registration, login, and
update and delete profile") and reference ("Import Namespace") that file
from within my code behind file verse using a totally separate code behind
..vb file for all of my .aspx files.

Conclusion:
..aspx file + CodeBehind File + BizLogic File = Success
OR
..aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

[Kevin Spencer]

Hi Leon,

"N-Tier" is a nice buzz word that seems to get passed around a lot these
days. I would advise you not to think about tiers, but about principles
instead. If you can do so successfully, the tiers will take care of
themselves.

What are the principles? Well, you stated some of them yourself:

I want the application to be easy to
maintenance as well as extend.
That is the chief purpose of all these high-sounding terms that get tossed
around these days, like "MVC" and "N-Tiered." What is it that makes an app
easy to maintain, and easy to extend? Well, organization is the key, and
separation of the various types of functionality is the idea. For example,
you can certainly visualize the difference between a User Interface object,
such as a Web Control, and a Business Logic object, such as a class that
organizes and maintains all functionality for a single user of your app. One
renders HTML in the browser, so that the user can read and interact with it.
Another contains data and functionality for manipulating a set of data.

The key is to keep these "loosely coupled." That is, don't mix them
together. An application, whether it is an executable or a web app, is never
finished, at least until nobody is using it any more. Typically, apps are
launched, and then revised, and re-launched, and revised, etc. etc. etc.
There are several logical divisions of functionality, one of which I have
already mentioned: User Interface vs. Business Logic. A good web app
separates UI from Business logic, so that it is easy to make changes to one
or the other without having to think about the other. The UI is bound to the
business class by some programming interface, which you generally don't want
to change. However, beyond that, you may want to change the way the data
looks when displayed, or you may change the underlying structure of the
data, or enhance functionality without breaking the User Interface.

If you first organize the various logical elements of your app, and keep
them loosely coupled, maintanance and extensibility should be a snap. Of
course, the planning and organization are the most critical parts of the
process. They are the foundation upon which you build. There are many ways
to separate out the various elements. For example, in our web app, we use
custom Server Controls for various functionality. These Server Controls are
built in such a way that they can operate independently of each other. That
way, we can combine, move, and/or revise any of them without affecting the
rest of the app. The Server Controls are all UI, no business Logic. For
that, our Server Controls use Business classes, which handle and manipulate
the data. In addition, we use CSS for layout and positioning. This means
that our developers don't have to think about what the UI will look like to
the user. Our graphic designers create the CSS that handles this.

One final word of advice: Bone up on OOP (Object-Oriented Programming).
Forget about "CodeBehind." A CodeBehind class is just that: a class. It is
much like any other class. It is best to think about classes, not files.
Files exist on the file system. Classes exist in an application. Once the
app is compiled, the files are irrelevant. And thinking in terms of files
only confuses the issue.

Don't use Modules. They are there for backwards compatibility, a kind of
crutch for VB developers who are migrating to OOP and .Net. A Module is
actually compiled to a class, but a static class. However, you can create
any static methods, properties, etc., that you need without ever touching a
Module.And static elements are not as useful as you would think in the .Net
environment. Get used to thinking OOP. It is uncomfortable at first, but
becomes intuitive in a relatively short period of time.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Leon" <vn*****@msn.com> wrote in message
news:#g**************@TK2MSFTNGP09.phx.gbl... Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic designers but we are locally accessible. I want the application to be easy to
maintenance as well as extend. Plus I think if I use a .vb that contain all of "let say" user interaction information ("such as registration, login, and update and delete profile") and reference ("Import Namespace") that file
from within my code behind file verse using a totally separate code behind
.vb file for all of my .aspx files.

Conclusion:
.aspx file + CodeBehind File + BizLogic File = Success
OR
.aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

[Leon]

Thanks Kevin,

I understand exactly what you are saying, but when I spoke of Business
Objects/Logic I meant the .vb code page which include Public Classes.
Example:
.....
.....
Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

Are You Talking about the same thing? "I trying to make sure I fully
understand you"

Background Information:
I acceptable understanding OOP, but no way a professional.

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:u4**************@TK2MSFTNGP15.phx.gbl...

Hi Leon,

"N-Tier" is a nice buzz word that seems to get passed around a lot these
days. I would advise you not to think about tiers, but about principles
instead. If you can do so successfully, the tiers will take care of
themselves.

What are the principles? Well, you stated some of them yourself:

I want the application to be easy to
maintenance as well as extend.

That is the chief purpose of all these high-sounding terms that get tossed
around these days, like "MVC" and "N-Tiered." What is it that makes an app
easy to maintain, and easy to extend? Well, organization is the key, and
separation of the various types of functionality is the idea. For example,
you can certainly visualize the difference between a User Interface
object,
such as a Web Control, and a Business Logic object, such as a class that
organizes and maintains all functionality for a single user of your app.
One
renders HTML in the browser, so that the user can read and interact with
it.
Another contains data and functionality for manipulating a set of data.

The key is to keep these "loosely coupled." That is, don't mix them
together. An application, whether it is an executable or a web app, is
never
finished, at least until nobody is using it any more. Typically, apps are
launched, and then revised, and re-launched, and revised, etc. etc. etc.
There are several logical divisions of functionality, one of which I have
already mentioned: User Interface vs. Business Logic. A good web app
separates UI from Business logic, so that it is easy to make changes to
one
or the other without having to think about the other. The UI is bound to
the
business class by some programming interface, which you generally don't
want
to change. However, beyond that, you may want to change the way the data
looks when displayed, or you may change the underlying structure of the
data, or enhance functionality without breaking the User Interface.

If you first organize the various logical elements of your app, and keep
them loosely coupled, maintanance and extensibility should be a snap. Of
course, the planning and organization are the most critical parts of the
process. They are the foundation upon which you build. There are many ways
to separate out the various elements. For example, in our web app, we use
custom Server Controls for various functionality. These Server Controls
are
built in such a way that they can operate independently of each other.
That
way, we can combine, move, and/or revise any of them without affecting the
rest of the app. The Server Controls are all UI, no business Logic. For
that, our Server Controls use Business classes, which handle and
manipulate
the data. In addition, we use CSS for layout and positioning. This means
that our developers don't have to think about what the UI will look like
to
the user. Our graphic designers create the CSS that handles this.

One final word of advice: Bone up on OOP (Object-Oriented Programming).
Forget about "CodeBehind." A CodeBehind class is just that: a class. It is
much like any other class. It is best to think about classes, not files.
Files exist on the file system. Classes exist in an application. Once the
app is compiled, the files are irrelevant. And thinking in terms of files
only confuses the issue.

Don't use Modules. They are there for backwards compatibility, a kind of
crutch for VB developers who are migrating to OOP and .Net. A Module is
actually compiled to a class, but a static class. However, you can create
any static methods, properties, etc., that you need without ever touching
a
Module.And static elements are not as useful as you would think in the
.Net
environment. Get used to thinking OOP. It is uncomfortable at first, but
becomes intuitive in a relatively short period of time.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Leon" <vn*****@msn.com> wrote in message
news:#g**************@TK2MSFTNGP09.phx.gbl...

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic

designers

but we are locally accessible. I want the application to be easy to
maintenance as well as extend. Plus I think if I use a .vb that contain

all

of "let say" user interaction information ("such as registration, login,

and

update and delete profile") and reference ("Import Namespace") that file
from within my code behind file verse using a totally separate code
behind
.vb file for all of my .aspx files.

Conclusion:
.aspx file + CodeBehind File + BizLogic File = Success
OR
.aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

[Kevin Spencer]

Hi Leon,

Again, forget about files and pages. Think in terms of objects. A single
file can contain multiple class definitions. And the file is only used at
compile-time to build the classes. In other words, try to think of these
things as abstract entities, not files. The code to create them is in files,
but the entities themselves are not.

For example,let's take a look at your example:

Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace
This is a class definition. It is NOT a class. A class is an instance of the
definition. You can have many User objects, each with its own set of data,
different from the rest, but sharing the same class definition. So, how can
every User object be a file? There is only one file. And it is not used at
run-time; an in-memory object is.

A class is a type, just like Integer or String. If it helps you to think of
it this way, note that you can have many Integers or Strings in an
application. The only thing they share in common is their data type. And
remember that "Integer" (the type) is not a number. It is the definition of
what an Integer is. It's the same thing with a class. A class definition
simply defines the type of data that a class is. A class (the type) is not
an instance of a class any more than Integer is a number, or String is a
string.

I hope this doesn't sound nit-picky, but it is extremely important to think
of these things in this way to be successful with OOP.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Leon" <vn*****@msn.com> wrote in message
news:Op*************@tk2msftngp13.phx.gbl... Thanks Kevin,

I understand exactly what you are saying, but when I spoke of Business
Objects/Logic I meant the .vb code page which include Public Classes.
Example:
....
....
Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

Are You Talking about the same thing? "I trying to make sure I fully
understand you"

Background Information:
I acceptable understanding OOP, but no way a professional.

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:u4**************@TK2MSFTNGP15.phx.gbl...

Hi Leon,

"N-Tier" is a nice buzz word that seems to get passed around a lot these
days. I would advise you not to think about tiers, but about principles
instead. If you can do so successfully, the tiers will take care of
themselves.

What are the principles? Well, you stated some of them yourself:

I want the application to be easy to
maintenance as well as extend.

That is the chief purpose of all these high-sounding terms that get tossed around these days, like "MVC" and "N-Tiered." What is it that makes an app easy to maintain, and easy to extend? Well, organization is the key, and
separation of the various types of functionality is the idea. For example, you can certainly visualize the difference between a User Interface
object,
such as a Web Control, and a Business Logic object, such as a class that
organizes and maintains all functionality for a single user of your app.
One
renders HTML in the browser, so that the user can read and interact with
it.
Another contains data and functionality for manipulating a set of data.

The key is to keep these "loosely coupled." That is, don't mix them
together. An application, whether it is an executable or a web app, is
never
finished, at least until nobody is using it any more. Typically, apps are launched, and then revised, and re-launched, and revised, etc. etc. etc.
There are several logical divisions of functionality, one of which I have already mentioned: User Interface vs. Business Logic. A good web app
separates UI from Business logic, so that it is easy to make changes to
one
or the other without having to think about the other. The UI is bound to
the
business class by some programming interface, which you generally don't
want
to change. However, beyond that, you may want to change the way the data
looks when displayed, or you may change the underlying structure of the
data, or enhance functionality without breaking the User Interface.

If you first organize the various logical elements of your app, and keep
them loosely coupled, maintanance and extensibility should be a snap. Of
course, the planning and organization are the most critical parts of the
process. They are the foundation upon which you build. There are many ways to separate out the various elements. For example, in our web app, we use custom Server Controls for various functionality. These Server Controls
are
built in such a way that they can operate independently of each other.
That
way, we can combine, move, and/or revise any of them without affecting the rest of the app. The Server Controls are all UI, no business Logic. For
that, our Server Controls use Business classes, which handle and
manipulate
the data. In addition, we use CSS for layout and positioning. This means
that our developers don't have to think about what the UI will look like
to
the user. Our graphic designers create the CSS that handles this.

One final word of advice: Bone up on OOP (Object-Oriented Programming).
Forget about "CodeBehind." A CodeBehind class is just that: a class. It is much like any other class. It is best to think about classes, not files.
Files exist on the file system. Classes exist in an application. Once the app is compiled, the files are irrelevant. And thinking in terms of files only confuses the issue.

Don't use Modules. They are there for backwards compatibility, a kind of
crutch for VB developers who are migrating to OOP and .Net. A Module is
actually compiled to a class, but a static class. However, you can create any static methods, properties, etc., that you need without ever touching a
Module.And static elements are not as useful as you would think in the
.Net
environment. Get used to thinking OOP. It is uncomfortable at first, but
becomes intuitive in a relatively short period of time.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Leon" <vn*****@msn.com> wrote in message
news:#g**************@TK2MSFTNGP09.phx.gbl...

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic

designers

but we are locally accessible. I want the application to be easy to
maintenance as well as extend. Plus I think if I use a .vb that contain

all

of "let say" user interaction information ("such as registration, login,

and

update and delete profile") and reference ("Import Namespace") that

file from within my code behind file verse using a totally separate code
behind
.vb file for all of my .aspx files.

Conclusion:
.aspx file + CodeBehind File + BizLogic File = Success
OR
.aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

[Leon]

I think I know exactly what you are talking about, but I will now start to
tighten-up on my OOP skills.
thanks Kevin!

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl...

Hi Leon,

Again, forget about files and pages. Think in terms of objects. A single
file can contain multiple class definitions. And the file is only used at
compile-time to build the classes. In other words, try to think of these
things as abstract entities, not files. The code to create them is in
files,
but the entities themselves are not.

For example,let's take a look at your example:

Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

This is a class definition. It is NOT a class. A class is an instance of
the
definition. You can have many User objects, each with its own set of data,
different from the rest, but sharing the same class definition. So, how
can
every User object be a file? There is only one file. And it is not used at
run-time; an in-memory object is.

A class is a type, just like Integer or String. If it helps you to think
of
it this way, note that you can have many Integers or Strings in an
application. The only thing they share in common is their data type. And
remember that "Integer" (the type) is not a number. It is the definition
of
what an Integer is. It's the same thing with a class. A class definition
simply defines the type of data that a class is. A class (the type) is not
an instance of a class any more than Integer is a number, or String is a
string.

I hope this doesn't sound nit-picky, but it is extremely important to
think
of these things in this way to be successful with OOP.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

"Leon" <vn*****@msn.com> wrote in message
news:Op*************@tk2msftngp13.phx.gbl...

Thanks Kevin,

I understand exactly what you are saying, but when I spoke of Business
Objects/Logic I meant the .vb code page which include Public Classes.
Example:
....
....
Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

Are You Talking about the same thing? "I trying to make sure I fully
understand you"

Background Information:
I acceptable understanding OOP, but no way a professional.

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:u4**************@TK2MSFTNGP15.phx.gbl...

> Hi Leon,
>
> "N-Tier" is a nice buzz word that seems to get passed around a lot
> these
> days. I would advise you not to think about tiers, but about
> principles
> instead. If you can do so successfully, the tiers will take care of
> themselves.
>
> What are the principles? Well, you stated some of them yourself:
>
>> I want the application to be easy to
>> maintenance as well as extend.
>
> That is the chief purpose of all these high-sounding terms that get tossed > around these days, like "MVC" and "N-Tiered." What is it that makes an app > easy to maintain, and easy to extend? Well, organization is the key,
> and
> separation of the various types of functionality is the idea. For example, > you can certainly visualize the difference between a User Interface
> object,
> such as a Web Control, and a Business Logic object, such as a class
> that
> organizes and maintains all functionality for a single user of your
> app.
> One
> renders HTML in the browser, so that the user can read and interact
> with
> it.
> Another contains data and functionality for manipulating a set of data.
>
> The key is to keep these "loosely coupled." That is, don't mix them
> together. An application, whether it is an executable or a web app, is
> never
> finished, at least until nobody is using it any more. Typically, apps are > launched, and then revised, and re-launched, and revised, etc. etc.
> etc.
> There are several logical divisions of functionality, one of which I have > already mentioned: User Interface vs. Business Logic. A good web app
> separates UI from Business logic, so that it is easy to make changes to
> one
> or the other without having to think about the other. The UI is bound
> to
> the
> business class by some programming interface, which you generally don't
> want
> to change. However, beyond that, you may want to change the way the
> data
> looks when displayed, or you may change the underlying structure of the
> data, or enhance functionality without breaking the User Interface.
>
> If you first organize the various logical elements of your app, and
> keep
> them loosely coupled, maintanance and extensibility should be a snap.
> Of
> course, the planning and organization are the most critical parts of
> the
> process. They are the foundation upon which you build. There are many ways > to separate out the various elements. For example, in our web app, we use > custom Server Controls for various functionality. These Server Controls
> are
> built in such a way that they can operate independently of each other.
> That
> way, we can combine, move, and/or revise any of them without affecting the > rest of the app. The Server Controls are all UI, no business Logic. For
> that, our Server Controls use Business classes, which handle and
> manipulate
> the data. In addition, we use CSS for layout and positioning. This
> means
> that our developers don't have to think about what the UI will look
> like
> to
> the user. Our graphic designers create the CSS that handles this.
>
> One final word of advice: Bone up on OOP (Object-Oriented Programming).
> Forget about "CodeBehind." A CodeBehind class is just that: a class. It is > much like any other class. It is best to think about classes, not
> files.
> Files exist on the file system. Classes exist in an application. Once the > app is compiled, the files are irrelevant. And thinking in terms of files > only confuses the issue.
>
> Don't use Modules. They are there for backwards compatibility, a kind
> of
> crutch for VB developers who are migrating to OOP and .Net. A Module is
> actually compiled to a class, but a static class. However, you can create > any static methods, properties, etc., that you need without ever touching > a
> Module.And static elements are not as useful as you would think in the
> .Net
> environment. Get used to thinking OOP. It is uncomfortable at first,
> but
> becomes intuitive in a relatively short period of time.
>
> --
> HTH,
> Kevin Spencer
> .Net Developer
> Microsoft MVP
> I get paid good money to
> solve puzzles for a living
>
> "Leon" <vn*****@msn.com> wrote in message
> news:#g**************@TK2MSFTNGP09.phx.gbl...
>> Is it a good idea to use visual studios .net code default solution and
>> compile business object (business rules and logic) together? or is
>> code
>> behind sufficient enough? I know about modules, but I think they are a
>> little too much for the application am developing.
>>
>> background Information:
>> I'm working on a web application with multiple programmers/graphic
> designers
>> but we are locally accessible. I want the application to be easy to
>> maintenance as well as extend. Plus I think if I use a .vb that
>> contain
> all
>> of "let say" user interaction information ("such as registration, login, > and
>> update and delete profile") and reference ("Import Namespace") that file >> from within my code behind file verse using a totally separate code
>> behind
>> .vb file for all of my .aspx files.
>>
>> Conclusion:
>> .aspx file + CodeBehind File + BizLogic File = Success
>> OR
>> .aspx File + CodeBehind File = Success
>>
>> "What's Your Opinion?"
>>
>> Thanks
>>
>>
>>
>
>

[Leo Muller]

I have had the same considerations, and recently reconsidered and revised
the way we worked.
The evolution is like this:
1- used only code behind. Major disadvantage, no code reuse.
2 - wrote another project with the shared functions, worked good, but a bit
of trouble with the references used to other projects, while being used by
different programmers.
3- used a certain class in the project to give the shared functionality,
solved previous problem, but still not perfect. Mainly because this class
would be copied over to different projects.
4 - The best solution so far: - wrote my own namespace (solution with
projects) with all shared functions. Within this I compiled the Microsoft
Data Application Block as well. Copy the DLL over to a directory accessible
by all programmers. Let them set reference to this DLL. (not to the
project!). and use the class as mycomp.data.sqlhelper, or
mycomp.text.countwords(). Can be developed seperately, and released whenever
they are ready.
If anyone want the sourcecode of this project, just let me know. The way it
works is soooo simple and straighforward, I just want to develop in order to
use it! Call me a freak.

Now the great point of .Net is that changing between these different ways of
working is surprisingly easy.

Leo Muller
"Leon" <vn*****@msn.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic
designers but we are locally accessible. I want the application to be easy
to maintenance as well as extend. Plus I think if I use a .vb that contain
all of "let say" user interaction information ("such as registration,
login, and update and delete profile") and reference ("Import Namespace")
that file from within my code behind file verse using a totally separate
code behind .vb file for all of my .aspx files.

Conclusion:
.aspx file + CodeBehind File + BizLogic File = Success
OR
.aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

[Leon]

I understand exactly what you are saying, but I think it's good idea to use
both CodeBehind as well as the compile dll using the vbc.exe Compile this
allows
you to further separate code from presentation right. What's your opinion?

"Leo Muller" <le***@keshet-i.com> wrote in message
news:cj**********@news2.netvision.net.il...

I have had the same considerations, and recently reconsidered and revised
the way we worked.
The evolution is like this:
1- used only code behind. Major disadvantage, no code reuse.
2 - wrote another project with the shared functions, worked good, but a
bit of trouble with the references used to other projects, while being
used by different programmers.
3- used a certain class in the project to give the shared functionality,
solved previous problem, but still not perfect. Mainly because this class
would be copied over to different projects.
4 - The best solution so far: - wrote my own namespace (solution with
projects) with all shared functions. Within this I compiled the Microsoft
Data Application Block as well. Copy the DLL over to a directory
accessible by all programmers. Let them set reference to this DLL. (not to
the project!). and use the class as mycomp.data.sqlhelper, or
mycomp.text.countwords(). Can be developed seperately, and released
whenever they are ready.
If anyone want the sourcecode of this project, just let me know. The way
it works is soooo simple and straighforward, I just want to develop in
order to use it! Call me a freak.

Now the great point of .Net is that changing between these different ways
of working is surprisingly easy.

Leo Muller
"Leon" <vn*****@msn.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic
designers but we are locally accessible. I want the application to be
easy to maintenance as well as extend. Plus I think if I use a .vb that
contain all of "let say" user interaction information ("such as
registration, login, and update and delete profile") and reference
("Import Namespace") that file from within my code behind file verse
using a totally separate code behind .vb file for all of my .aspx files.

Conclusion:
.aspx file + CodeBehind File + BizLogic File = Success
OR
.aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks