I have an existing WCF RIA project built on the Release Candidate; I'm now moving to the Release version & have discovered many changes. David Scruggs made the following comment on his (MSDN) blog:
"If you’ve written anything in
SIlverlight 4 RIA Services, you’ll
need to rewrite it. There has been a
lot of refactoring and namespace
moves."
Having made a brief attempt to compile the old solution with the new RIA framework I'm inclined to agree. My current plan is to:
remove the Silverlight Business Application projects from the Solution
rebuild the EF4 items from the database
create a new Silverlight Business Application project
re-add the files (XAML, CS) from the old Silverlight Business Application project
Does this sound like a reasonable approach? I think it's cleaner than trying to manually alter the existing project.
If your project started with a Silverlight Business Application then yes, that is a decent way to go about it.
There are quite a few changes in that template that your work will depend on, so having the base code working again makes it easier to do the minor tweaks needed. For me it was mostly namespaces, but having all of the Login controls throwing a fit over namespaces and undefined type etc, makes it feel like more of a problem than it is.
Related
I try do my projects with clean architecture. I use Entity Framework. Everything is good and easy to know. I have structure like this - Domain, Application, Infrastructure etc. I create my project without any big problems - WebApi project. Now I would like to add Blazor server side project. What is the right way? Only add Blazor project to my existing solution? Here is few problems for me. I will have the logic of two applications linked (handlers). And I have some nuget packages which contains webapi specializations. When I create own solution for blazor app here is only one problem. The duplicate of dbcontext. I need "duplicate" (I can use only 2 tables if I need) domain project with entites and dbcontext in infrastructure. But then it work's good and it's clear. But I don't think it's good way to duplicate domain project. And where is stored migrations?
I know if projects will microservices it will be super clear and it's makes sense. But when I have monolith and would like WebApi and Blazor app with one database what's right way?
What is the right way?
As always - it depends.
In the Uncle Bob's article on the Clean Architecture the following point is present:
Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
If your Blazor App can be considered just another UI (without major changes to the business rules, though it can have some specific use cases) then it should be a part of the current solution.
I was Studying a course in PluralSight in clean-architecture by Gill Cleeren, they the Blazor project to the same solution
The point of Clean Architecture is that you do not have to duplicate shared logic. Blazor server project is a "front-end" layer at the edge of your application. If implemented correctly you will reference the other projects just like your WebAPI does.
Try to add a Blazor Server project to your solution and reference the Application/Infrastructure/Domain projects that already exist and you should be able to re-use all the exisitng logic.
Blazor (and WebAPI) is nothing more than a way to present your data, so keep it that way.
Does anyone know how to do this? I built a backend c# class in asp.net but want to access these same classes without recreating them in silverlight. Is this a possibility?
You can reuse the cs files by adding them to your project AS LINK. Right click in your project and select Add Existing...Browse to your file and in the Open Button, use the pulldown arrow on the right to select Add As Link. You will see the file added to your project with an icon that with the little Windows Shortcut icon overlayed on it.
Just remember - the ASP.Net runs on the .Net runtime. Silverlight runs on the CoreCLR (Silverlight runtime.) Not everything that compiles in oone will compile in the other...
To separate things a little bit, #if directives can help, you can also use Partial Classes and partial methods (to add content that only runs on the server or on the client.)
RIA Services is definitely the way to go for sharing code between ASP.Net and Silverlight.
As well as the previously mentioned generation of domain service models, it also lets you share individual files between the web-app and Silverlight by simply inserting "shared" in to the filenames. e.g. "MyClass.shared.cs".
RIA services does not take long to get to terms with (and there are good tutorials about). Try this one.
Well, ASP.NET itself isn't going to work (ditto many of the full libraries), but I'm assuming you just mean you local domain model etc.
IIRC you can try to simply reference it, but it may well generate a warning message. Of course you need to be exceptionally careful not to use anything that the other platform doesn't support...
IMO, the better option here is to create a second csproj that includes the same .cs files (or cheat with a wildcard/deep include). And build both. Same C#, different dll/platform.
Is isn't uncommon to find that you need a very small usage of #if directives, too.
WCF RIA Services may help you solve your problem. Silverlight does not use the same runtime as ASP.Net does and you cannot directly share assemblies containing model classes on the client and the server side. To solve that WCF RIA Services will transparently generate classes on the client side based on model classes on the server side. Obviously WCF RIA Services will also allow you to create, read, update and delete objects of these classes using a web service.
MSDN has more specific information about WCF RIA Services Client Code Generation.
I googled this a little but couldn't find a good result.
Right now I'm building a web site and I'm trying to make it as correct as possible from a design point of view from the beginning.
The problem I'm now facing is that when deciding to start with logging I needed a project to place this code in. As I could not find a suitable place in my currect projects I thought: hey, why not a logging class library?
Is there a general guideline on how many projects you should have? I know this would be a rather small project but it would be nice to entirely get it out of my way!
Any hints are appreciated :)
Absolutely you should have a logging library. And if you're going to make this as 'correct as possible from a design point of view' and your proect is less than trivial then you should definitely have some number of projects. The thing is, we have no idea what you're working on besides the fact that it's a web app. It's the biz domain that often determines how complex your solution has to be.
I'd go for a three-tier architecture for a small project.
This would include:
Application Layer
Business Layer
Data Layer
but if you want to add logging, it would be best to create another project. This would also help you so that if you want to add logging to another application, you can just include the logging project.
Either way would work, if you are concerned about project limit in a solutions. Don't be.
I myself would put it in a separate project or a utility project.
We have a solution with 200+ projects. The downside is long load time in Visual Studio. But past that the only issue is making sure you have enough RAM.
Also, MSBuild.exe has built-in support for SLN files, so look into using that instead of Visual Studio if you are doing automated builds.
"That which changes together should be packaged together", I forget where that guideline comes from (Code Complete maybe?).
In other words your assemblies (projects) should represent a coherent abstraction in the same way your classes/objects do at a lower level.
So yes, a separate logging project is the right way to go (although do check out log4net or Microsoft's logging block before you roll your own!)
Put a logging into a separate project is perfectly fine.However it really depends on the scope of your project.I normally setup my project like this
YourProject.Web(web project)
YourProject.Core(all the business logic)
YourProject.Web.Tests(Watin tests)
YourProject.Web.Core.UnitTests(Unit tests)
YourProject.Web.Core.IntegrationTests(Integration tests)
I suggest you to download some open source Project from asp.net to see how the project have been organized.
Currently I'm working with a big, old and extremely poorly written ASP.NET 1.1 application and the continuous maintenance is becoming quite a problem. Basically it's reaching breaking point and I'm reluctant to expand it any more than I have to as demanded by the business. Based on my experience creating other projects from scratch it would really suit an ASP.NET MVC based solution. Oh how I wish the world were that simple...
The fact is that I just cannot justify re-writing it from scratch and the business cannot afford it. The ideal solution would be to start writing an MVC-based application alongside it and begin a slow migration as new requirements arise.
I've read posts which state that this is entirely possible, but in my experiments I've not found it so easy. The current application contains several large data access and business logic layers shared by other applications that the company produces. These are also written in 1.1 and will not compile in 2.0 (and would destroy the other projects if I tried!) so I cannot upgrade them. Since I can't do that I'm stuck with an application that cannot even be opened in a .NET 3.5 capable visual studio. The new MVC app would also have to make use of these layers.
I am entirely open to suggestions. I'm desperate to find a solution that I can quickly demonstrate would allow me to improve the product immensely without taking too much time or affecting the rest of the business.
You could write a WCF service on top of the existing business layer and have your new app talk to that service instead of referencing the business layer directly.
You need to divide to conquer. Analyse the current app and its layers and see if you find a way to divide each significant piece of functionality into a discrete area with as few changes as possible.
Then make each area a unique service using the old technology.
Then you can rewrite each service slowly as you can fit it in and not affect the whole.
Otherwise you are going to have to come up with a convincing business case for your managers so that they allocate you the time to do the job properly. Sometimes our job is political as well as technical.
We have a base product that has bespoke development for each client that extends and overwrites the functionality of the base.
We also have a custom framework that the base product and sits on top of.
We use inherited forms to override the base functionality and to date all the forms and classes have been lumped in the same projects i.e. UI, Data, Business...
We need to clean up the code base now to allow multiple client project to run off the base product at once and I was looking for advice around the following areas:
Ways of organising the solution to fit with the above requirements, the number of projects in the solution is quite large and we want to reduce this to increase developer productivity, we are think of making the Framework DLL references instead of project references
Are there any build and deployment tricks we are missing, we currently have a half automated build and release process
What is the best way to manage versioning
Any best practices for product development
I personally strongly believe that highly modular architecture will fit here nicely: core application should provide basic/common services, and all customer-specific functionality should be implemented as plug-ins (think MEF). Hence, several thoughts:
I'd go for one solution for core application plus additional solution for each and every customer.
One-step build is a must. Just invest some time in writing a handful of MSBuild scripts: this will pay off tenfold.
See APR's Version Numbering for inspiration.
Too broad a question.
I can give you an advice on your first question and maybe a little of the forth : If i were you I would go with a framework DLL solution that could easily be managed and futher developed by a team and different solutions for each subsequest project. However, the framework solution would have to be propely developed, with extra care to one design principle: Open/closed principle [1] so future development of the framework does not break the existing implementations.
[1] http://en.wikipedia.org/wiki/Open/closed_principle