You're very welcome! It was what initially popped into my head - though I believe there is probably a stronger and ideal way to carry such a project out with regards to the large amounts of data you will be dealing with.
What is the best approach for client-server application? I need to start develop website+database+crm+backoffice. I am developing in c# working with SQL server 2008.
I would like someone to direct me on how to build my server side smart&simple or hard&complex ? What is best to build an entity for each store procedure I have or deploying to my client side all tables needed and let the client handle the data ?
What is the best approach for client-server application?
FIRST, collect requirements. SECOND, create the architecture and/or design. Which of these is needed depends on the requirements. THIRD, based on the architecture/design decide what technologies to use.
or hard&complex ?
Very hard/complex when one skips the first two steps above.
Hmmm, you're mixing and matching things a lot here. As you're creating movable "things", you should consider the fact that each one of these is a separate movable type. This indicates that you should consider the fact that you're using an enum and change it to something like this:
// Add base implementation
publicclass Legs : MovableObject
// Do something
publicclass Wheels : MovableObject
// Do something
And there you have it - it's a lot cleaner and simpler to work with OO features.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
Thus objects would be Entity MovementWings MovementLegs MovementWheels.
And you set it by calling. entity.setMovement(Movement)
The Movement itself is either enable/disabled (where 'enable' means to actually allow movement) so each Movement object would have a property to enable it. Then Entity could call that if it has Movement (if internal varible is not null.)
Hello: I'm working on a large database project that I currently have in VBA/Access 2007 and intend to put into VB.Net/Access 2007 as I think it might be a better idea but I'm not sure. This program is for a large law case where I will be required to deploy it by sending it out on disks to various other firms across the country. I'm a bit rusty with this so I want to know the best way to handle the solution. If all these other firms don't have Access, what other type of database should I use? What is the best practice for deployment?
What does "large" mean? Presumably you mean a lot of data versus a lot of users.
Using .Net should eliminate the problem of them not having MS Access. MS Access is the GUI part with some other additionally functionality, but is not required to actually access the data. However testing is always a good idea.
Member 8385949 wrote:
If all these other firms don't have Access, what other type of database should I use?
Alternatives really depend on exactly what the application is doing and what "large" means.
... i think this may become a potentially heated debate but really i'm just hoping to hear from somebody with Crystal Ball (i.e. not interested in what's Right, what's Wrong, what's Cool and what's not) - I just want to know "what's going to happen"
While I have no doubt we'll all be coding under "Desktop" environment for years to come, that "Desktop" isn't going away. However, is this a hint that .NET is legacy? That WinRT is the shiny new API that us lowly developer should all adopt? Is M$ giving us a hint (shivers up my spline this reminds me of Silverlight M$ is very generous when it comes to wasting our time)
what I am thinking is, worst come to worst, our investment in server side will remain "Desktop" - we only consider any "Metro" development for GUI side. GUI (metro/WinRT) and server (Desktop/.NET) communicates via socket - but not sure if wiring down byte array will work or not. I am pretty sure an Int32 (what about IList/IDictionary or even DataTable) gets wired back/forth correctly serializing/de-serializing using .NET DataContractSerializer, just not sure what further complication.
Also wonder how easy/difficult will it be to port .NET code to WinRT (For example I suspect while C# be same on both platform, but platform API such as File.AppendAllLines will probably be different). Remember porting your .NET dll's to now dead Silverlight? (That SL enforces generics? Sh*t that's manual changes everywhere what were they thinking - I read somewhere WinRT too they will take away all the non-generic collections)