I have Silverlight Application. Getting started with Linq I find out I have to make mapping in a new project in the entire solution. To use generated classes from new project I use "Add Reference". For Silverlight Application it is possible to add reference only to the same kind of Project.
Here I got the problem because in Silverlight Applications it's impossible to right-click on the project Add ->New Item -> LINQ to SQL Classes.
Perhaps entire idea of using classes from different Projects is stupid in this situation... Please help =)
The Silverlight code executes client-side. LINQ to SQL will execute server-side. You need a way to get your LINQ to SQL objects accross the wire to your Silverlight client. The easiest way to do this is with WCF RIA Services http://www.silverlight.net/learn/advanced-techniques/wcf-ria-services/using-wcf-ria-services.
Firstly, you won't be able to use Linq-to-SQL in silverlight, as silverlight will never be able to connect directly to SQLServer. The only way to use Linq-to-SQL with Silverlight would be to create a service on your web server (WCF or something else) that uses L2S. Silverlight will then communicate with the service which in turn will communicate with SQLServer.
An easy way to share code between Silverlight and a non-Silverlight project is to share the files, rather than a binary reference (which is what you are trying to do). Select Project->Add Existing Files... from the original project. That way, the original project will compile in its format, and Silverlight will compile the same code into its format.
You might want to look at WCF RIA Services if you want to do data access from a Silverlight application, it simplifies the process a lot, and generates the services I mentioned above for you.
Related
Business strikes again - and we need to make a new website. I'm not sure how to pull this off, but basically , I need to make a MeteorJS project which can talk to a c# backend. We all know that ASP.NET and MeteorJS is two different platforms, but seems my company wants to use both methodologies at the same time.
So as I asked in the title, is it possible to create a MeteorJS project, add it as a project to visual studio, and have it talk to an ASP.NET backend? If so - what are the steps I need to take in order to accomplish this?
If your C# project can expose a number of REST interfaces then Meteor can easily consume those and be "just a front-end". You won't get reactivity unless you use Apollo for your data access layer.
We released a WPF client server application this year . It has a client (with a few dlls ) and server on the server machine (with multiple dlls with most of our logic). The server side uses Entity Framework and the service between them is TCP /IP Windows communication foundation (WCF).
The client uses MS Prism with Mef for MVVM. The UI has a number of Datagrids for storing , saving data.
For WPF we have :
XAMl -> View Model -> Service Interface -> Server Side code -> DB
For ASP.NET , we expect to use the layers from Service Interface onwards as it is.
So , basically we need :
Website-> Logic for data handling on client Service Interface -> Server Side code -> DB
Unit testability is not a very major concern as our unit test coverage looks good on the server side (85 % covered).
I read up on ASP.NET MVC and found some tutorials that spoke about building whole applications on the MVC framework .
Our case we have more than half of the application built and only need the client side web UI with same data .
My question is : Should we go for ASP.NET Web forms or MVC ?
Web forms have native controls like GridView which can be used. MVC doesnt provide much native controls support . MVC covers the whole web app full stack. We only need the client UI website.
People around have recommended MVC since it is new and looks like the way forward but I am wondering if it would be overkill considering our requirements ( only need client). Would MVC force us to rework our whole layers even on the server side ? Will aSP.NET web forms not do this ? We want to be able to use WCF instead of doing any other http framework like webapi.
I know this question has been done to death with but these are some speicific requirements here. I also read up on porting WPF apps to Web but tat probably wont work out as we may have some fucntionalties different in the Web vs WPF.
Having worked with both MVC and Web Forms I would highly recommend going with MVC. In my opinion Web Forms is an antiquated pain-in-the ass that doesn't lend itself well to scaling or unit testing(which I know you said is not a huge concern).
Yes, Webforms has native controls like gridviews but you aren't missing out on much. These are good for very simple things but as soon as you add some complexity to your tabular data you're going to be pulling your hair out. What I'm trying to say is you can accomplish the same thing these built-in controls provide but with greater flexibility using simple tables or just plain old divs(and some css, of course).
I should also note that both MVC and web forms work just fine w/ WCF. You don't have to use WebApi if you're using MVC.
Lastly, I don't think there's an easy way of only providing "the client" piece of what your trying to accomplish with Microsoft technologies. If I understand your question correctly, you have a desktop application and now you want to provide a web-based equivalent UI. You're going to have to create a site using webforms or MVC to achieve that. However, you will be able to reuse your web services so you won't have to rewrite too much business logic.
You are making a small confusion. Since you have alredy a WCF(SOAP) backend service you will write only the UIClient, regardes of technology. You can do it even in Java.
Since you rewrite the desktop client, as a new web client you have to do it from scratch, and so should use ASP.MVC. You can find a lot of forums which can tell you why.
Web API is used, only if you want to create REST services in MVC. But you can build them also in WCF if you really need them.
The only good reason for ASP.NET, will the fact if you have developers which already know it, and you can save some money.
I've a rather large and complex MSSQL-Database model and want to display/edit these data from mobile apps (Android/iOS at least, best Windows Phone, too) built on top of Xamarin.
What's the best approach for this?
Some findings:
Ok, I was thinking about exposing the Database as REST-Service, using e.g. a tool like
dreamfactory.com to be able to switch later to another backend-database without changing a lot.
On the Xamarin-Client-Side there is a Simple REST-Client available:
http://components.xamarin.com/view/restsharp
And for creating the Cross-Platform-Forms there is now Xamarin.Forms.
=> But where can I add "custom server side logic"? OK, I could do this in another server-side C# application which is filling/processing the database.
=> But isn't there a better way to "wire" directly the REST-Calls with the Forms-Elements? Type of generating some basic code and then just edit it to adapt to conrete needs?
Or are there even other frameworks available which work more efficiently in such a situation? It can not be a "cloud-only" framework, e.g. something like wakanda.org (where I can deploy the server part for free on my own -virtual- windows server).
PS: I need native code in Xamarin on the mobile app-side, I can't use just HTML/jQuery.Mobile.
One option to consider is ServiceStack. It would be easy to pull down the SQL Server database structure into POCO's using T4 templates. ServiceStack.OrmLite will work on iOS and Android but unfortunately not with WP8. ServiceStack also has its own web service framework with fast JSON serializers and ProtoBuffer plugins. This would be one option to use to maximize code share. The ServiceStack version 4 is on commercial license, V3 is BSD licensed.
With minor code tweaks you could use SQLite.Net on the mobile side so you can include WP8 as well.
I have a specific case and I want to know the best practice way to handle it.
I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :
We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.
After that we add references to the resulted dll in the framework.
And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.
It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!
What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .
How to refactor my code so I can do this?
The most important thing is :
Never publish the whole framework if the change in any dependent application, just publish the updated part belongs to this application .
If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.
If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.
The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping algorithms in your client applications... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!
Developing WCF web services is quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.
I totally agree with levib, but I also have some tips:
As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!
A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.
Check them out! :)
Decades of experience says: avoid the framework and you won't have a problem to solve.
Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.
Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.
Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.
I want to consume a series of REST services from a provider. But there are a lot of functions I can call and send to the server, so I think it would be a good idea to create a separate library that my C#/MVC2 project can reference and call.
In VS2010, what is the correct project I should select to create this new library? Just plain old "Class library?" It's grouped under "Windows" so I don't know if the correct template to use for a web project.
Thanks.
"Class Library" would be fine. The Class library template is not tied to anyone particular type of project, so they can be used for Web, Console, Windows, Wpf etc.
Of course the functionality you provide in the Class library might be limited to a specific execution evironment because of the functionality you might put into the library, for example if you develop a bunch of functions that expect to be run in an ASP.NET environment then the functionality of the class library might not be applicable to a Console application.
Technically, yes, a "Class library" will give you what you want. Consider, however, whether there are any potential benefits for you in creating a proxy Web Service that you use as an intermediary between your own application(s) and the remote provider. Doing so allows additional management options that can be performed separately from the calling application.
You could also try the MSDN REST Starter Kit. It contains VS templates that help you do all the RESTful things you could ever imagine doing.