Hello all,

I was wondering if anyone could give me any advice on how much easier a Web App would be with LLBLGEN as opposed to developing a distributed system.

Our requirements/tools are as follows - All dotnet platform - Internal usage (we have control over everything) - We will be in charge of the service side and the client side and always will be - Transfer speed is not a huge issue - Development cost and time to market is the biggest issue for us.

Which is the best technology to use to do this in conjunction with LLBLGEN? (It is a CRM/Invoicing type application)

I'm leaning towards Remoting with WCF. I'm dead scared however that there will be lots of overhead with developing this. (We started off using Webservices exposing the DAL as datasets and have already made that costly mistake...ewww). All ways of developing correct SOA implementations seem to me to have rediculous overheads compared with a regular stand alone application.

It seams alot quicker and easier to just do a regular website, however with that comes the overhead and inflexability of the UI. (For mine winforms is so much quicker to develop)

I've been reading about this for months and I just cant seem to come up with an answer...I feel like I may as well just stick my hand in a hat and pick a random number...then dive in....(ie...screw it up for the poor old maintenance guy )

Thank you kindly for anyone's advice. John Sheppard

Web application development is so easy and rich these days, with all of the available controls out there, and the AJAX controls and LLBLGen Pro DataSources, it's a piece of cake

Please check our we examples posted in the download section of www.llblgen.com

Walaa wrote:

Web application development is so easy and rich these days, with all of the available controls out there, and the AJAX controls and LLBLGen Pro DataSources, it's a piece of cake

Perhaps. However I see a trend in growing complexity, even more so with ajax. Problems are sometimes very hard to find and avoid.

We're currently developing a multi-site POS software using .net remoting and I fully understand your concern. Here's my advice, if you can fulfill the requirements with a web app, you shouldn't hesitate. Of course web apps aren't as flexible as winform apps but as Walaa said, there's still a lot you can do. If you don't mind buying a commercial control library like devExpress, it's possible to quickly develop a nice ajax-enabled UI. You just have to make sure that you don't need direct access to local resources (serial ports, peripherals), printers don't count because printing from a web app isn't a problem at all.

Furthermore, it's much more convenient to debug a web application than any client-server app. To begin with, you don't have the object marshaling layer to care about (although llblgen does most of the job for you) and more importantly, you avoid a lot of exception handling headaches (deny of service, unavailable server, lost connections).

There's also a lot to say about ease of deployment, only ONE server to update! No need to run installers on every client machine, to phone people and explain them that they must stop using the software during the update process. (I consider updates to be the most costly operation in our company).

stefcl wrote:

There's also a lot to say about ease of deployment, only ONE server to update! No need to run installers on every client machine, to phone people and explain them that they must stop using the software during the update process. (I consider updates to be the most costly operation in our company).

Did you ever try ClickOnce?

mihies wrote:

stefcl wrote:

There's also a lot to say about ease of deployment, only ONE server to update! No need to run installers on every client machine, to phone people and explain them that they must stop using the software during the update process. (I consider updates to be the most costly operation in our company).

Did you ever try ClickOnce?

Yes, but unfortunately our requirements are very high, currently we have : - 1 client app on every computer - 1 database per site - 1 service app per site

ClickOnce would be ok for the client apps but how about the database and the service app, and it's not only a matter of replacing the binaries, there are things like config files which may require an update... Furthermore, it's required that every component in every site runs the same version. It might be a good idea to ask for advice on that forum, but for now, It sure wouldn't be nice to hijack this thread.

Using asp.net won't help you that much since you still have to distribute the database and asp.net application. If you go with clickonce you'd have to distribute client installation files as well (clients would autoupdate themself). Or am I missing something?

A single customer may have multiple shops which result in multiple sites. These sites need to be updated one by one, not even talking about the representatives who are around the world with their laptop. If there was a single central server with a single database to update, don't you think it would make deployment easier? That's why I maintain that web applications are easier to update...

So, these: - 1 database per site - 1 service app per site are not the requirements.

Then, ClickOnce still can help you. The only thing you'll have to watch for is the situation when you update client installation while clients are running. This isn't hard to solve. Just compare the versions on each request to server app and require update if the versions don't match (update might be just client restart).

I played around a bit with clickonce deployment and never got it working correctly. We currently use innosetup and down the track intended to roll our own auto update. It may have been improved in vs2008.

We own the DevExpress components and they are great. Owning components like that are a no brainer I think.

I do think winform apps are easier to prototype and quicker to build regardless and while I agree deployment is a big thing my biggest issue is the overhead with creating a webservice and debugging it.

Everywhere I read suggests we should not pass predicates to a webservice but pass parameters. This in my view creates a whole bunch of extra work and maintenance that is just not there with webapps. This is how we currently do our webservice (passing predicats and exposiong the DAL as the webservice with datasets).

To a certain extent I understand why this is a bad idea, but I'm still a bit of a newbie. Most of the arguements put forth for these I understand and agree with, just in our circumstances they dont seem to really apply (although note the newb thing). We just want a regular desktop app that has the database on a remote computer. Thats the only extra requirement over a regular desktop app.

Thank you for any advice.