I have been programming in VB6 for a few years and now I have taken up VB.Net. I have developed a couple solutions, but the solutions are not up to common design standards. I am the only developer in a financial business. My solutions work, but I don't have anyone to learn from about correct architecture.
I am developing a new application and I want it to be done right. However, I don't know what should be a class/object etc. I think I use too many global variables and nothing is encapsulated.
The application is for expense submissions. The user (the user should be a class?) can enter an expense with line items. I am using a datagridview to show/add the line items.
There will also be a history tab that shows all the expenses for the user, and a review tab so that a reviewer on the expenses can approve line items.
Data is in SQL Server several tables, one for the expense header, one for the expense lines, one for user info. Approved expenses are inserted into a third party app on the same SQL Server database for payment.
What approach would you use in designing a simple app like this? Thank you for any advice you can give me.
You need to do a lot more studying. However one thing I've found useful for quickly developing object models without worrying too much about the database aspects is the Entity Framework. Add an Entity Model to your project and read up on that.
Related
I realize this question has been asked in different forms but not quite in the same context as this so forgive me please.
I am developing a web based video game. I have a library of over 5000 abilities, spells, skills, character classes, races, etc.
I want the client to receive information from the game library upon request from the server.
My first instinct was to create a library of all of the data in my SQL database, however since the data is static I am not sure if it would be best practice to create objects in my server-side code to store the information.
If anyone can provide some insight I'd appreciate it.
Thanks.
EDIT: I'd like to add to most of the library items have roughly 256 characters of text (descriptions) along with the game related data.
5000 elements is a trivial amount of data for any modern DBMS to manage. If you are considering using a DBMS to manage this data, this would be advantageous over statically defining them in the server side code.
Separation of data from the "business logic" of running the game is very important. This allows you to add new definitions of items in the game, and customize the game without needing to modify any of your executable code to do so. This is also known as the Model/View/Controller design pattern.
We are going to develop a medium-large customized web app for a private company using MVC 4 and EF 5.
Early analysis and previous experiences on that business field show that it will have more than 150 tables/entities and because our customer isn't a software engineer and we know that our data model will change many times through the progress of the project.
Now, my Q is which approach is better for us according of the following:
1) Causes less effort on updating data model and data store because of many changes that will occur.
2) Takes less time to create the data store and helps progress the project faster.
Note: This app will work with big sets of data (10k, 100k objects for some entities). However, it will have few (and maybe sometimes no) concurrent requests and online users.
Thanks in advance
I think the term
because our customer isn't a software engineer and we know that our
data model will change many times
Is a reality but is not the whole reason of data model change in many times!
BTW some suggestions may be helpful
Consider business analysis a key point and do continues business analysis
More and more investing on analysis will cause less cost on development and change management
Have a specific talented analyst as a representative positioned in the customer office.
Have a specific representative of customer accountable for analysis and development team.
Document the customers business process, talk about them with the customer. Document the negotiation results.
Design and change management
Never design the database alone. Brainstorming team member, invite customer representative, invite business analyst, have a DBA in design team, have a Change-Manager role.
Technology
Have a look on technology trend (may using a document-based database will be helpful)
Have a flexible framework and architecture in service of business software production and not in reverse!
Changes will come ... be ready
Changes will come, all above efforts are targeted to optimized the solution to cost less when change happen, they will not prevent the changes.
You need to have an acceptable mechanism to bill them to the customer
ITIL's Service-level management, SLA and OLA will be a guide line.
So the question answers:
1) All above will help on the problem. Continues interactive analysis first, next design and develop in iterations, using template approach.Changs will come and they will cost.
2) Depends on technology and frameworks, there will be tools (I don't know EF) just don't insist on a specific platform or library.
Hope this helps.
I can recommend you to use CodeFirst structure. Because your classes will be clear and mainly you work with classes much in business logic.
I'm a non-technical (well, non-software. hardware background) founder who has hired a pretty good developer that has built a site with backend on Rails and frontend with CSS/HTML pretty capably. our next step is to develop a Yodlee integration, and we both want to know how long it takes to do this. He has an estimate which I think is reasonable, but would like feedback from the community without biasing the responses.
Also, if anybody has done an implementation before, I would really appreciate your perspective and help!
I have implemented a complex Yodlee integration for a LA based start-up over the last two years. They built a social game and money management platform on top of it. The short answer is that it's tough and dirty work.
The technical aspect of getting your application to communicate to the Yodlee API is not at all the hard part (its pretty much a standard web service). Following are some aspects highlighting the difficulty:
The most difficult part is dealing with the unknowns and the variability in the client data.
There is effectively no documentation for the API
There are several way to do each operation that will return different data
Ive been designing and building systems for 15 years and have gotten pretty good at estimating projects. We were way off with Yodlee; in fact we are still dealing with issues.
In order to understand why its so tough, you really need to understand what Yodlee is.. it is an aggregator of 10,000 different systems. Now these other systems might be big professional systems like Bank of America, Chase, ... but they are often small little banks (Bob's Bank in Omaha).
When Yodlee communicates with the big companies (they are called content services) there is most always an api that actually returns good data. But with the little ones, they are doing screen scraping. You can imagine that breaks all the time. They have an entire team in India which is just focused on that.
The other issue is about modelling the data; each of the content services at its source has modeled the data differentley (different names, different elements, different relationships,...) but Yodlee but combine all 10,000 models into one view. What this leaves you with is a very bloated model, where you can never know or count on getting a certain data element.
To give you an idea... there are extra fields about a credit account (apr, credit amount, last payment, ...) beyond the standard base'class fields (balance, ...). While this sounds great that you have this data, in practice the number of content services that provide these extra data elements is so low that you cant really depend on them. I'd say that the fidelity of those data elements is very low. All you can really count on is the base elements (account name, type, balance) and (transaction date, description and type).
Speaking of transactions... their transaction categorization system is not that good. They have clearly taken a breadth first approach to this, rather than focus on accuracy. We built an entire system for transaction categorization which is far more effective.
A couple other things: The DAG account test system is useless; it does not operate the same way real accounts do. You will be far better off opening 5-10 accounts at different content services and giving your developers the username/passwords for these for testing. The MFA (multifactor auth) system for account security has been an endless headache. This isnt Yodlee's fault, its the nature of the game. The banks are doing more and more crazy things that add security layers. Yodlee has the MFA system in place to compensate for this. At any given time about 20% of our accounts are in error for some reason. We have built an entire component just to manage this.
So what does this all mean? Double your estimate, get ready to get dirty. I dont want to put Yodlee down at all (except for the lack of documentation); they really are solving a hard problem. There really arent any other better options.
I run the team responsible for sales and support of the Yodlee APIs so the response may be a little biased.
I have seen clients get up and running in anywhere from 10 days to 3 months to 6 months. The time to implement depends on the number of fields in the data model you are using and how you are going to use the data or manipulate it before presenting it to your users.
While the most prevalent data fields such as account balance or transaction amount will always be available, Craig is right, as you get into the broader data model you will have to code for exceptions when the data is not there. Yodlee does provide documentation on how often the fields will be available to help with this process. But if you are only going to be using basic account and transactional information, you will not have to worry about these complexities and it will speed implementation.
How you use the data once you receive it from Yodlee will also play a big part in the time it takes to get integrated. If you are deriving additional data from the transaction descriptions or are doing something with categorization then there is more complexity and it will require more time. If you are using many of the fields as-is, then this will be easier.
The other item that Craig mentioned is the extra security questions (Multi-factor Authentication). While that section of the API does add some work, we have added documentation around this to make integration easier. Also, with any development issues that come up we give clients access to a developer forum that is monitored by our Technical Consulting team.
I have a contact manager program that I'd like to design for multiple network marketing companies. My desired structure would include a core program which covers basic contact management functions. After that one could purchase a module for their specific network marketing company. This module would contain a variety of controls that the original program would need to be able to manipulate. Here is an example of what it would have to have:
A group box containing buttons that link to a genealogy view, and the option to import one's donwnline from the back office provided by a company.
A panel which is displayed on the contact page allowing the user to input business information or which will be filled by importing a downline from the back office: ie business ID, qualification level, sponsor information etc.
a panel displayed when one searches for contacts on the contact list page which allows the user to sort based on information such as when they joined, what their business id is and so forth.
a panel which is displayed in a personal business overview page which presents to an individual how many people in their downline are at each qualification level and develop a mailing list for individuals of a certain qualification level.
I have the code developed to perform all these functions, I just wanted to give you an example of what needed to be done. I'm thinking that what I'm trying to create is a library that one can download and the program will recognize, but I'm not really sure where to go. What I'm really trying to do is figure out what kind of file I can make that will contain all this code and the GUI information that the program will recognize.
Any ideas?
With thanks,
John
Well, my solution would be to do it not in a plug-in style, but what I like to think of as a "custom update" style with database integration. The way you would do it is do a specific update for a company by making a .msi installer or something similar for the "new" (or old) version of the program for them. This could do anything from installing the original, clean version of the program, or installing another version with the code changes made specifically for them. Project-wise, it would be best to store these changes in separate folders, as in a SVN or CVS repository.
Now, take this with a grain of salt, since this may be a lot of work, depending on how many "updates" you are planning on doing. Of course, this could be what you're looking for because, once you have an update, you don't have to reprogram it to distribute it to another company. You just branch it and make any necessary changes to the already existing code.
It appears that the last comment on those forums proved to be the most helpful. I ended up with a design where the main program is the host and the interface. I've been taking a while to absorb how the assembly code operates in the hopes of learning more about it...that's how I learn really...mess and tinker with things, read descriptions and try using in different scenarios. This is a little challenging to debug but I'm growing confident that I'm heading in the right direction.
I have been offered by my employer to work on SAP Business Objects to analyse large amount of data they have.
I have the following doubts before I could accept that:
a. I love programming and do not want to lose touch with it. Do you think working on this tool would excite a person who loves building software? Or Is it like most part of the tool configurable through Wizard like interface?
b. Is this tool capable of working on data collected for research and testing purpose?
I tried googling but all I could get is some videos which mentions "Business Intelligence" more than 12 times a minute. Any suggestion or even links to help me make the preliminary analysis would be helpful. Thanks...
Business Objects is not rocket science. A competent developer should be able to figure out how to build a universe in a few days. My first experience took me about two days to figure out how to build a universe and another two days or so to get some analytic reports out of it.
However, 'research data' suggests that the actual structure of the data will vary depending on the nature of the survey so you will probably find yourself constantly making ad-hoc changes or new bespoke universes for each job. Business Objects is probably a reasonably flexible way to do this (a custom universe for a tabular set of research data could probably be set up in a few hours). However, the job would basically devolve to a reporting analyst position.
If you're not a 'tools guy' by nature you will probably find this sort of work unsatisfying. I do full life-cycle work on data warehouse systems and from time to time this involves developing front ends using Business Objects. I'm quite happy to work with it casually as part of a larger job but I wouldn't want a job solely working with just one reporting tool.
If you think of yourself as a programmer I would recommend against accepting the job if it was limited to just working with Business Objects.
I have experience working with Designer and reporting in Business Objects... Honestly, it's quite easy. I have to say I'm a total programmer at heart, and absolutely hate working with it, but that's what possessed me to write a program that uses the DLL's to automate everything. I enjoyed automating it, and ended up making a program that did in about 5 minutes what it previously took me weeks to do. Now all the BO developers use it, and I mostly spend my time updating that.
In summary... It sucks to work with when it's +60% of your job, but you don't have to lose out on Programming. If anything, I think I've improved my programming. Now I barely do the crappy side of the work. I just run my program, and everything works out.
I'm not sure what you are asking in question "B".