dbTalk Databases Forums  

Visual Studio Server Explorer, MV Datasources

comp.databases.pick comp.databases.pick


Discuss Visual Studio Server Explorer, MV Datasources in the comp.databases.pick forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Tony Gravagno
 
Posts: n/a

Default Visual Studio Server Explorer, MV Datasources - 08-26-2010 , 08:25 PM






Recent comments on re-working KEXI for MV reminded me: we’re getting
close to being able to use the Visual Studio Server Explorer with a
Pick/MV back-end.

nospamNebula-RnD.com/blog/tech/mv/2010/08/vsmv1.html

T

Reply With Quote
  #2  
Old   
sh
 
Posts: n/a

Default Re: Visual Studio Server Explorer, MV Datasources - 08-27-2010 , 01:09 PM






You use Server Explorer to create GUI interfaces? Whatever happened to
separating the business and database layers from the interface layer?

I always use business objects, so I really don't have a use for your
Server Explorer for MV.

What am I missing here?

Sholom

On 8/26/2010 9:25 PM, Tony Gravagno wrote:
Quote:
Recent comments on re-working KEXI for MV reminded me: we’re getting
close to being able to use the Visual Studio Server Explorer with a
Pick/MV back-end.

nospamNebula-RnD.com/blog/tech/mv/2010/08/vsmv1.html

T

Reply With Quote
  #3  
Old   
Tony Gravagno
 
Posts: n/a

Default Re: Visual Studio Server Explorer, MV Datasources - 08-27-2010 , 03:59 PM



Good catch, Sholom.

Frankly, I don't do _that_ much SQL work to speak of. But when I do,
the server explorer is really a big help. It's close to the same UI
as the SQL Server Management Studio, but builtin to VS.

When I do real GUI work for a SQL DB, I'll generate an AEF context
(business objects) from the relational database. (I wrote utilities
to dynamically generate business class assemblies direct from a DB,
blogged about this some months ago.) With the strongly typed classes
I'll separate tiers as you indicate - the data access is usually in a
separate DLL. I only databind direct to the UI for prototypes and
quick ditties.

T

sh <shamada (AT) prupipe (DOT) com> wrote:

Quote:
You use Server Explorer to create GUI interfaces? Whatever happened to
separating the business and database layers from the interface layer?

I always use business objects, so I really don't have a use for your
Server Explorer for MV.

What am I missing here?

Sholom

On 8/26/2010 9:25 PM, Tony Gravagno wrote:
Recent comments on re-working KEXI for MV reminded me: we’re getting
close to being able to use the Visual Studio Server Explorer with a
Pick/MV back-end.

nospamNebula-RnD.com/blog/tech/mv/2010/08/vsmv1.html

T

Reply With Quote
  #4  
Old   
sh
 
Posts: n/a

Default Re: Visual Studio Server Explorer, MV Datasources - 08-30-2010 , 08:44 AM



Got me thinking - if VS can generate all the layers into a single GUI
form, why can't it generate them into separate objects?

I guess it's because business objects are a somewhat personal thing. My
business objects are fairly simple affairs, because my needs aren't all
that complex. However, I've seen some business objects frameworks that
are truly quite complex, and are way overkill for my needs.

BTW, Tony, have you used mv.NET with Silverlight yet? I wonder if
Silverlight is the way to go. For me, it surely is the simplest way to
transition from thick-client VB.NET to thin-client. But that would only
be true because my applications are only used in-house, and I can fully
control what is on the client machines.

Sholom

On 8/27/2010 4:59 PM, Tony Gravagno wrote:
Quote:
Good catch, Sholom.

Frankly, I don't do _that_ much SQL work to speak of. But when I do,
the server explorer is really a big help. It's close to the same UI
as the SQL Server Management Studio, but builtin to VS.

When I do real GUI work for a SQL DB, I'll generate an AEF context
(business objects) from the relational database. (I wrote utilities
to dynamically generate business class assemblies direct from a DB,
blogged about this some months ago.) With the strongly typed classes
I'll separate tiers as you indicate - the data access is usually in a
separate DLL. I only databind direct to the UI for prototypes and
quick ditties.

T

sh<shamada (AT) prupipe (DOT) com> wrote:

You use Server Explorer to create GUI interfaces? Whatever happened to
separating the business and database layers from the interface layer?

I always use business objects, so I really don't have a use for your
Server Explorer for MV.

What am I missing here?

Sholom

On 8/26/2010 9:25 PM, Tony Gravagno wrote:
Recent comments on re-working KEXI for MV reminded me: we’re getting
close to being able to use the Visual Studio Server Explorer with a
Pick/MV back-end.

nospamNebula-RnD.com/blog/tech/mv/2010/08/vsmv1.html

T


Reply With Quote
  #5  
Old   
Tony Gravagno
 
Posts: n/a

Default Re: Visual Studio Server Explorer, MV Datasources - 09-01-2010 , 02:28 PM



I'll preface that I am an advanced student with VS and .NET ORM
technologies, not an expert. Feel free to correct a comment if you
know better.

sh wrote:

Quote:
Got me thinking - if VS can generate all the layers into a single GUI
form, why can't it generate them into separate objects?
Not sure I understand the question. There are tools for doing that, I
just chose to roll my own. When you drop components on a form it
creates an adapter, essentially objects, which you can then use in
code-behind to access the datasource.

Quote:
I guess it's because business objects are a somewhat personal thing. My
business objects are fairly simple affairs, because my needs aren't all
that complex. However, I've seen some business objects frameworks that
are truly quite complex, and are way overkill for my needs.
Sort of random responses here...
Most Pick people and products in this industry tend to approach
business objects from a file perspective: Customer, OrderHeader,
OrderDetail, Inventory, etc. Those are storage media, not business
entities. A real business object is a combination of files and fields
which present a view, which is logical for some specific purpose. So
we'll have a Data Access Layer (containing all of those files) from
which we can create subsets of Business Access Layers for specific
screens, projects, etc. I've spent a lot of time with CSLA,
NHibernate, and other frameworks, and tools to build them like
..NetTiers for CodeSmith. (Even wrote a MV provider but with only one
person in the world other than myself interested in this, even as open
source, I decided not to maintain it.) Yeah, they can be way overkill
but working with a consistent interface can become a real pleasure
too. mv.NET Solution Objects is the NHibernate for MV. I really like
it.


Quote:
BTW, Tony, have you used mv.NET with Silverlight yet? I wonder if
Silverlight is the way to go. For me, it surely is the simplest way to
transition from thick-client VB.NET to thin-client. But that would only
be true because my applications are only used in-house, and I can fully
control what is on the client machines.

Sholom
I've blogged about Silverlight compared to Flash/Flex, Java applets
and similar tools. These browser plugins are now accepted by almost
everyone except the most fundamentalist luddites. They're a mechanism
for rendering very rich user interfaces without the issues associated
with cross-browser DHTML/CSS/JavaScript coding. For internal and
external use, Silverlight is great, and for external use it no longer
carries the stigma that it and other plugins once had.

I recommend becoming familiar with the options:
- Thick-client WinForms
- Thin-Client: WebForms
- Thin-Client: MVC
- Rich-Client: Silverlight
There's no "right" answer, it depends on your skills and preferences,
but most importantly on the task and audience ... right tools for the
job 'n all...

No, I haven't used mv.NET with Silverlight yet but I need to soon.
The latest mv.NET v4.2 introduces tight integration with Silverlight
that simply doesn't exist anywhere else in the MV world, and it
greatly simplifies development for that target platform. VS2010
includes significant improvements for Silverlight 4 developers, so
mv.NET 4.2 presents the most value to VS2010 users. I haven't
installed VS2010 yet, as most of my clients are quite comfortable with
..NET 2-3.5. .NET 4 is just a geek toy to me at the moment, and aside
from Silverlight I don't have any compelling reasons to load VS2010.

That said, as a worldwide Distributor and support provider for mv.NET,
I have an obligation to get familiar with the platforms it supports,
and since that includes all of these new releases, I will be compelled
to install and get familiar with all of the hooks within the next
couple weeks. Sigh - the luddites don't have it all wrong...

T

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.